UPDATE: We heard back from Aardvark Media “The Slug and Lettuce website does not store your password in plain text. At time of account creation, we send a one-time email with the plain-text password, as we’ve found sites that do this see a marked drop in the number of users of any “Forgotten password” facility they provide.” Well that’s a relief! For the full response, see the comments section below.

Anyone who works in web development (should) know about security issues when it comes to storing data—especially passwords! One of the simplest security errors is storing users’ passwords in plain text. That’s just stupid. Why would you store passwords in plain text? Plenty of Fish do, and as dspillett from hackernews puts it “My opinion? PoF stores password in plain text because it is an unprofessional outfit with no care for the security of its users or their data.” Storing a password in a retrievable encrypted format doesn’t cut it, either; it only takes one rogue or unhappy employee or your database stolen, and your passwords could be at risk.

Let’s admit it: the main problem here is password reuse. If you use a different password for every account you log into, having one password stolen (from the system with the weak link) will (hopefully) only result in a few random forum postings. If you have the same password to your bank account that you do for a random forum your friend made on a weekend, chances are your password is just waiting to be stolen, along with your money. Here is a comic from xkcd about password reuse.

Regardless of the reuse issue, when a website or webapp is storing your details, they have a level of responsibility to make sure it’s kept safe. If a website includes its own very clever way to store passwords, it’s probably broken and not very safe at all. Using already existing libraries to handle password hash storage makes sense. These libraries are generally open-source reviewed by people who understand them. As the saying goes, “If it ain’t broke, don’t fix it.” What happens when it does break, though? Crackers will always try to find quicker and slicker ways of cracking, and rainbow tables did just that (assuming they stole your database of hashed passwords). In the past, using an MD5 or SHA1 hash with a salt was good enough not to be cracked within a reasonable time.

Luckily, some clever folks came up with bcrypt, an (effectively) adaptable hashing algorithm that can keep up with Moore’s Law. It uses Blowfish at its core and salts, but the main benefit of bcrypt over something like SHA512 is it was designed to be slow; it’s not really a hashing algorithm. Hashing algorithms are designed to digest a large amount of data and provide a string which can be compared with another to check for message integrity. They are fast by design. Some discussion over which is better still remains, but from what I can tell, bcrypt is going to be secure longer.

We’ve established you should be using trusted, well-used code for authentication, and I hope I’ve made it pretty clear that it’s not acceptable (but unprofessional) to send users their passwords in plain text via email! There are ALTERNATIVE ways to do the whole “Forgotten Password” thing. I was sent my password in plain text after sign-up. Why? I can only assume because someone thought that convenience was better than security. They were wrong. They are wrong. Very wrong. Wrong wrong wrong.

Wrong.

To make sure it’s not just my opinion that it’s bad, I asked a few people on Twitter if there was ever a valid reason. Here are a few responses…

@relequestual no.

31/01/2012 4:02 PM via Twitter for MacReplyRetweetFavorite

@phillipcaudell

Phillip Caudell

@relequestual Definitely not. Anyone who says otherwise hasn't properly thought things through.

31/01/2012 4:04 PM via EchofonReplyRetweetFavorite

@Angry_Lawyer

Tony Aldridge

@relequestual spying?

31/01/2012 4:03 PM via Twitter for MacReplyRetweetFavorite

@skippychalmers

James Chalmers

@relequestual no but I suspect a lot of older systems either don't encrypt or have a way for a password to be shown in plaintext

31/01/2012 4:10 PM via Twitterrific for MacReplyRetweetFavorite

@grahamcrosbie

Graham Crosbie

The trouble is, Graham is right. There are, and probably always will be, a number of systems and websites out there that do it wrong and either can’t or won’t ever be upgraded. A way you can deal with this, is to use different passwords for every account, which are impossible to remember. Personally I use LastPass, which is a very secure way of storing your passwords, and making them accessible. If you want to know exactly how it works, check out this transcript from an episode of Security Now (A fantastic and recommended security podcast). The main point, is they never store your decryption key, and you only ever send them encrypted data, as encryption and decryption is done client side. Plus, it has a few really neat extra authentication methods for the super paranoid.

A final note on password strength: I’m sick if seeing password requirements of “must include upper and lower case, must include 3 numbers and 2 special characters.” No. It DOES make it more secure if you don’t handle brute force attempts by not locking accounts, but there is a BETTER way, which makes brute force even harder, as this xkcd comic shows…

The next time you are responsible for implementing the authentication element of a website, think. Remember this comic. Suggest to your users not to reuse passwords. Explain to them that you won’t be sending them their password in an email for THEIR protection. If you fail to do these things, you really aren’t helping the current state of username and password authentication.

Developed an authentication system before? Let us know how and why in the comments below.

© Relequestual for TechRant, 2012. | Permalink | 2 comments | Add to del.icio.us
Post tags: algorithm, authentication, bcrypt, Blowfish, libraries, passwords, rant, xkcd

There seem to be two camps of developers these days. The first are those who read books—physical books you can put in your lap. The second group are those individuals who consume all of their research material online. I would place myself somewhere in the middle for the very same reason that the second group exists: finding content online is very easy. I’d far rather pick up a good book and read the printed pages than to read a web page or blog article, but like so many others, find doing so impractical in a society where all the facts you’ll ever want are just a click away.

There’s something very satisfying about sitting down with a physical printed book and a cup of coffee and reading about the subject and learning new things. I don’t find that using web resources offers me a comparable experience as I tend to be looking for the solution to a very particular situation. I don’t pretend to know all the answers, but here are my views about what the future holds for printed reference material,  as well as trends I have noticed.

Why do I read books?

I can see in my room 14 different reference books on the topic of programming alone. Add that to my collection of recipe books and fiction—that’s a great deal of paper! So why do I find this at all practical or useful when Google holds all the answers?

It’s all about the mind-set of an individual. Call me old-fashioned, but I find that sitting down in the evening with a cup of hot chocolate and a novel is far more relaxing than watching television or playing a FPS. Neither should you call me a technophobe—I’m a computing student at Bournemouth University and worked for Microsoft on my placement year.

The truth is that I find it easier to consume a comprehensive documentation of one author’s thoughts on a broader subject base than a thousand authors’ thoughts on a thousand sub-topics. I prefer the subtle humour and the quality of material that you find only in printed books and not on a blog, for example. This quality is really the main reason for my preference of books. Publishing houses have very high standards and rigorous procedures to ensure the content is accurate and well worded. A post in a forum, for example, simply isn’t subject to these sorts of restrictions.

What about other developers?

I have a lot of developer friends, not only through my studies but also through my work. I’ve found that in general the older ones tended to have more books on their shelves than the younger ones. That said, I don’t know how often those books are picked up.

This raises another interesting point: in what way are these books read, and how often?

For me (and I know for others as well), the most significant factor considered is the time investment necessary. Developers, in particular, want answers quickly since their productivity relies on speedy response to questions. Reading a book cover to cover does take time, but that simply isn’t the way reference books are used. Personally, I read the introduction, maybe the first chapter, and then skip to whatever I’m most interested in; a process that on the surface appears to be the way people use the web—start off on Wikipedia, then read a few other results from Google.

Reference books are not designed to be read like a novel, they’re meant to be picked up and put down whenever and wherever needed. This is what makes a physical copy so good—you’d have a great deal of trouble reading a blog or forum on the London Underground, for example.

The Future…

I’ll stand up and defend the printed book as much as I can, but I must confess the web has some fantastic advantages over books—that is precisely what it was designed for in the first place.

• First, web sites are generally free to use. If I am looking for answers or wanting to learn something new, I’ll always find free reading material online. Printed books on the other hand are very expensive. Programming references for example, can often be found priced at £40—a significant investment by anyone’s standards.
• Second, the web is fantastically comprehensive. Regardless of the subject, no matter how obscure, the internet seems to hold the answer. Books, although comprehensive in their own right, are expensive to write and publish and, are therefore often cover a broad subject matter.
• Third, search engines such as Google or Bing make finding this content effortless. A few carefully selected keywords can bring you hundreds or thousands of relevant results.  A printed book is often a lot harder to get your hands on.

These three factors are, for me, the biggest reasons why I am using the internet more and more. There is a wealth of knowledge online which is simply unparalleled by any bookstore or library. With so many web sites designed for programming Q&A’s, blogs about development and tutorials sites, there is no shortage of resources to suit everyone.

There are many wildly different opinions about what the future holds for the printed word. The extremes: some believe that the internet has made books redundant already, other suggest that we will always have them.

So where does all this leave the printed book? Well, for me, as satisfying as holding a piece of dead tree might be, it simply isn’t as convenient as a web search. I see printed reference books becoming obsolete in 5 to 10 years. However, the quality offered by books over other online sources will surely guarantee their useful life beyond that. The future is quite clearly about eBooks. With the majority of publishers making their content available to providers such as Amazon with their Kindle platform, how long will it be before the printing presses fall silent altogether?

Next time you’re reading a tutorial or help forum online, ask yourself: ‘How does the quality of this compare to a book?’ and ‘Would I prefer to read this from paper?’

Let us know your thoughts on this subject and your predictions for the future of printed books.

Further Reading

• How novels came to terms with the internet  (Laura Miller, The Guardian, 15/01/2011)
• Is Google Making Us Stupid? (Nicholas Carr, The Atlantic, July 2008)
• The Net Effect (Beau Freidlander, LA Times, 09/11/2008)

© Jack.Hayter for TechRant, 2012. | Permalink | No comment | Add to del.icio.us
Post tags: books, ebooks, future, internet, publishing, reading

Recently, web designers have rallied under a new banner: ‘responsive web design’. The term coined by Ethan Marcotte and popularised by his book of the same name has caused something of a renaissance as to how we view the web. We always knew it was capable of fluid designs and that it wasn’t the same as print, but only now are we beginning to discover the full potential of what it means to make a website.

What is responsive web design?

A brief primer for the uninitiated: responsive web design is about shifting, omitting or adding content depending on the size or orientation of the display. For an example of this—and one of the first to do it before it had a name—was the ever-brilliant Jon Hicks. Resize your browser window and see how the columns remove themselves, the navigation re-positions itself, the logo scales proportionally; in short, it’s beautiful. To achieve this, Jon uses CSS media queries which are surprisingly well established.

So responsive web design, from a non-technical perspective, means more websites will be better optimised for your screen real estate than before as more designers use it. My real aim, though, is to talk to you about a lesser-talked-about technique that I believe falls under the same banner.

Context-aware browsing

Increasingly, sites will drop the navigation bar to follow you down the page. A couple of examples are TechCrunch and Creep Fest. I was trying to think of a name for this technique and did think context-aware browsing summed it up quite nicely, it knows where you are on the page and reacts accordingly until it dawned on me: This is another example of responsive web design!

An insightful overview of what’s currently happening to the web was described in Mike Driscoll’s Node.js and the JavaScript Age, we are transitioning from an age of static web pages to “a global digital nervous system”. I adore this analogy, HTML is the skeleton, content the organs, CSS the skin, and JavaScript the nervous system. With a combination of CSS and JavaScript, pages react to what the user does and where the user is, both geographically and within itself.

Advantages

• CSS media queries have a wide, standardised implementation. Even if the mobile browser you’re using doesn’t support it, it will support percentages in your CSS, so, if you’re using a grid system, simply drop 960px to 80% and you’ll have a fluid website at least.
• Your site will be more accessible to mobile device users. We know there are large shifts away from desktop usage and offering a streamlined experience, I believe, is a big part of that. Mobile users generally have different priorities to desktop users. On the B&W Meet website we decided that people would be looking for a map and location details so we made this a priority on the small-version of the site.
• Platform agnostic. It doesn’t matter if you’re using a Symbian browser or the latest Mobile Safari, it’ll behave the same lending itself to the “write once, deploy everywhere” paradigm.
• You have full control over the content positioning. There is no ‘magic’ attached to this, you simply use pure CSS to position content as you would in any other site.

Limitations

• More technical knowledge is required. To use techniques like navigation bars that stick to the top of the page past a certain point, JavaScript is essential.
• ‘The full experience’. Some believe that by providing an optimised view, that they are missing out on important content. Sometimes, this is the case; someone may make an editorial decision and decide that some content is superfluous for mobile users. I’m not convinced these people are using responsive web design ‘correctly’. It’s all about giving as similar experience as possible and prioritising content, not losing out on it.

Where next?

I believe this age of Responsive Web Design will see innovators playing with not only websites that respond, but online UIs too. Mobile users have different needs and priorities to desktop users and I believe many conventions can be taken from native mobile apps in this sense by taking these considerations into account. Next time you’re browsing TechCrunch or any other responsive website, ask yourself, ‘does this benefit me?’ and if so, ‘how’s it done, could it be executed better?’

Got any good or bad examples? Let us know!

© Fetimo for TechRant, 2011. | Permalink | No comment | Add to del.icio.us
Post tags: internet, responsive, web

Scheme

Image from Espos

As I imagine many of you do, I have a scheme to handle payments which is used in a good 80-90% of the projects I take on. Due to the nature of development work, projects can be anywhere from a week to 6 months long, but, in my experience, they more often than not come in around the 1-2 month mark. Bearing this mind, most clients with find it unacceptable for the entire project to be paid outright before any work is undertaken, and many developers will find it unacceptable to work for 2 months with no payment whatsoever.

• Client’s point of view – If everything is paid upfront, then there’s no guarantee that work will be done, and the individual and/or company involved won’t simply disappear with the money, and it’s very daunting to see a large sum suddenly leave your account.
• Developer’s point of view – If the project is large enough to require almost full attention continually for the duration of the project, then there will be no income over this time and (obviously) bills will need to be paid. This also being said, there’s a chance that you can complete the work and have the client refuse to pay, meaning you have wasted a lot of time and have a system that doesn’t really have a purpose.

With these points in mind, and in hope of keeping all parties happy, I offer a 4-payment scheme, which is broken down as follows:

1. 25% – Non-refundable deposit to guarantee my time
2. 25% – Once the design has been signed off
3. 25% – Once the system is complete
4. 25% – When the site goes live/Site is handed to client

A lot of the time, the last two payments fall at the same time, but on occasion, though a system will be complete, a client will want to do various other things (perhaps marketing) before the system is actually released. As standard practise, I will not hand over the code and IPR (if required) until the final sum is cleared.

The scheme above will be used as the basis for the rest of this article.

The Deposit

The deposit is an initial payment (more commonly weighing in at 25% of the total cost), which guarantees the time to work on your project, by covering the developer(s) for the first quarter of the project. As a personal rule, I won’t start work on a project until the deposit is made; as many of you can relate, at any one time I’ll have several quotes out, and to be perfectly honest, if I were to start a project with no deposit and another quote were accepted with a deposit, I’d be torn between two states of mind. I’d want to continue the work because I’d already started, but want to go on to the other project because (obviously) the client paid, and turning down money is just downright stupid.

Notes on deposits for clients

Please remember that simply saying that the deposit has been made isn’t sufficient. If the deposit hasn’t arrived in the account, then work simply won’t start on the project, and if it has been sent by cheque (we’ll get to these shortly) then work won’t start until I have set time aside to pay the cheque into the bank, and it has cleared successfully.

Always remember to pay your deposit via a BACS transfer (which is instant), and in a swift manner, so the work can be started.

Cheques

Image from dmjarvey

Oh, cheques—where to start with you little buggers!

Simply, cheques are the bane of my life. As a self-employed individual who doesn’t drive, I have to walk to the town centre to pay the cheque into the bank. It’s not the walking that bothers me; it’s the fact that the journey itself, there and back, will take me a total of an hour, plus the 10-30 minute wait in the bank to speak to somebody to get the cheque paid in. This means, in total, I have wasted around two hours—and simply walking to town and paying the cheque in and then walking back is a TOTAL waste of time.

So when I need to pay a cheque in, I have to schedule everything so people are aware I won’t be available for the majority of the day, and so I can do everything I need to do in the bank/town centre when I go up there, so not to waste a visit. All the while, I’m hoping that a client doesn’t attempt to contact me about something urgent or some new work.

Another thing is that cheques will more commonly be sent via post, and mysteriously disappear somewhere in the Royal Mail system. The rule of thumb here is that 9 times out of 10, if you post a cheque into a postbox before the postman empties it, it’ll be on the recipient’s desk by the following day—so using this as a way to delay paying is pointless. Also, a little side note for you:when a letter is received by Royal Mail, they stamp it, so when I received your cheque (posted two weeks ago, if I ever receive it, that is), I know that it wasn’t, in fact, posted, until the day before I received it.

I’d also like to point out, that of the 4 payments in my career that were made via a cheque, and sent via Royal Mail, I have received a grand total of 0.

Notes on cheques for clients

If you HAVE to send a cheque and there is no way around it, either deliver it yourself, or have it sent via recorded delivery. This way, you can check on the status as well as see who received it, as recorded deliveries require a recipient signature.

Do not say that the cheque has been sent, then actually send it a week or two later, because that gives us (the developers) the impression that you think we’re stupid, which is never a good start.

Final payments

The final payments are very important, especially if you actually want what you’ve paid for so far. Trying to skip out on these just simply won’t work.

Image from serenityphotographyltd

If you agreed to the original cost, and if there were any extra work involved, and there is written (email) proof that you acknowledged and accepted these charges, you simply cannot get out of paying. You can threaten legal action as much as you want, but I find it hard to believe, that, no matter how good a legal team you have, any court in its right mind would sanction an individual and/or company to hand over something that hasn’t been paid for in full, according to the original verbal/written contract, and according to any further amendments.

It’s my understanding that, in the eyes of the law, the IPR would reside with the developer until all payments are made and the requirements of the original contract are met.

More often than not, a client KNOWS that he’d stand no chance in a court, but simply threatens it because he wants to scare you into giving him the code so he can keep his money. Think about it like this: if he’s willing to pay the fees to have this taken to court, then why not just pay the goddamn final payments? Seriously!

Notes on final payments for client

If you refuse to pay the final payment, you can kick up as much of a fuss as you want. You just simply won’t be given the code—plain and simple.

But before you try to avoid paying for something you agreed to, take this hypothetical situation into consideration:

All the code has been done, and you’ve paid 3 of the 4 payments and you outright refuse to pay the fourth. As I stated previously, you’d have no grounds to force the developer to give you the code.

The developer now has a system that’s complete. He needs to get the money back for the work he’s done, and, providing there were no NDA’s and there is no reference, no logos, trademarks, copyrights or intellectual property of your company’s within this system, the developer can do as he pleases. At this point, he has three choices.

1. Write it off as unpaid and let the system sink to some directory on some backup hard drive
2. If the system is a nice one, and something that could be easily run and used as another source of income, he could rebrand it and set it up himself.
3. He could sell the system in hope of getting back the hours, if not making a nice little profit.

The first option is obviously the best from your point of view, but the worst from the developers point of view.

The second option is obviously bad for you. as you’ll need to spend time finding new developers to rip off; meanwhile, your old developer will be making money through a system originally built for you.

Now, if your business is in direct competition with another, then the chances are this system has something you competitors don’t—different features, or features based on theirs, but improved. Whatever the case, if this system were to go up for sale and the developer advertised it properly, individuals likely to be interested would be in the same sector as you, meaning that this system could simply be sold on to your biggest competitor and you’d have lost your edge, which will affect your business considerably.

Conclusion

My point here is to try to (hopefully) explain to those of you who try to skip out on deposits, or delay paying developers because you don’t have the funds, or you’d simply rather they did it for nothing, how this can have a negative affect on yourselves.

My understanding (which may be somewhat limited) is that all of the above practises are legal, if done correctly. (If this is not the case, feel free to contact me and clear some points up!)

If some points in this article appear somewhat harsh, or you believe that I am being unprofessional, I urge you to take a look around you and your own business. Everything mentioned here is pretty standard business practise, and, as harsh as it may seem, it’s just the way the world works.

Summary for clients on above section

Pay your developer, or you’ll get shafted—and the law will be on the developer’s side.

© Ollieread for TechRant, 2011. | Permalink | 5 comments | Add to del.icio.us
Post tags: freelance, pay, rant, work

So—as I was saying in the second part, I had to make two separate circuits. By doing so, I could have a dedicated power supply for the rocket igniter and one for the unnecessary circuitry. If you’re going to go out of your way to do something, you may as well overdo it!

After a chat with my friend, we decided on an adequately-sized box to house the circuitry, as well as 3/4 switches (each of different type), which need to be activated in a sequence. And with LED indicators, including flashing ones for more ‘over the top’ goodness, because you can never have too many LEDs.

Usually I would make a digital form of the circuit but I figured it’s a lot easier to draw this one (well, I say draw—it’s a rough plan, but it’s good enough!):

As you can see, even with all the added switches and flash circuitry, it’s still quite simple.  There are three switches, all of which  have to be on for the rocket to launch, as with the previous version.  The difference this time is that two of the switches are DPST (Double Pole, Single Throw).  A DPST is basically two SPST switches stuck together and controlled by a single mechanism.  An SPST is the most basic of switches: it is either on or off.  It has two terminals, which are either connected or not connected.  Therefore, a DPST has four terminals.  I opted for DPST switches because they allow me to control two things with one switch.  This alleviates the problem in the previous version of all the LEDs shorting out.

The first switch is a key switch. Why? Why not? We made this to be as over-the-top as we could!  So, to be able to use the launcher, you need a key.  Turning this turns on the launcher, which is indicated by a green LED.  The second switch is the arm switch, which has an obligatory switch cover to prevent accidental arming (again, not necessary, but over-the-top…). This switch also activates a blinking red LED, controlled by a 555 timer in astable configuration.  A 555 in this configuration generates square waves, in which you can choose the mark-space ratio of the waves, or duty cycle.  Below is the general schematic for an astable:

The rate at which it oscillates is dependent on R1, R2 and C.  They affect the charge and discharge rate of the capacitor C.  This was initially put on a breadboard to determine the correct “flash” rate.  R1 and R1 were initially potentiometers, thus making it easy to adjust.  Once we found the flashing rate we wanted, it was as simple as measuring the resistances and replacing them with a resistor of a set value.  The value of C also affects the rate in the respect that a larger capacitor will take longer to charge and discharge.  The final values I settled for were:

C = 100nF, R1 =330Ω , R2 = 10kΩ

Using those values, you can therefore calculate the ‘time on’ and ‘time off’.  The formulae can be found here.

The final switch is a momentary push-on switch.  The launch switch.  The switch that makes things happen!  This had a bypass resistor of 3300 kΩ.  I designed this launcher so it’ll tell me when I have everything connected up properly.  This is shown by a white LED, connected across the terminals of the arm switch, to act as a bypass when the switch is off.  Using high resistances to short the switches ensures that enough current flows around the entire circuit—but not enough to trigger the launch of the rocket.  Electricity always takes the path of least resistance, so activating the switches will bypass these resistors.

With all these factors decided, it was simple building the launcher. Below is the parts list:

• 1 x black ABS enclosure 150 * 80 *50 mm (£3.71)
• 1 x DPST key switch (£3.61)
• 1 x DPST toggle switch with cover (~£3.50)
• 1 x SPST momentary on switch (£1.39)
• 1 x veroboard 25 * 64mm (~£1.00)
• 1 x NE555 timer DIP8 (£0.44)
• 1 x DIP8 socket (few pence)
• 1 x BC548 NPN bipolar transistor (£0.15)
• 2 x ppp3 clips (£0.20)
• 1 x 4 AA battery holder (pp3 clip) (£1.19)
• 1 x two point terminal block (£0.10)
• 1 x white LED (few pence)
• 1 x red LED (few pence)
• 1 x Green LED(few pence)
• 1 x 100μF electrolytic capacitor (few pence)
• 1 x 10nF ceramic capacitor (few pence)
• 3 x 390Ω 0.25W resistor (few pence)
• 2 x 10kΩ 0.25W resistor (few pence)
• 1 x 3.3kΩ 0.25W resistor (few pence)
• 1 x 1kΩ 0.25W resistor (few pence)
• 1 x 330Ω 0.25W resistor (few pence)
• Wiring

The parts that are a few pence are usually bought in bulk, which makes them cheaper. The final price totals at around £16.29 (I added an extra pound to make up for the parts that are a few pence), excluding batteries. The items were sourced from Farnell and Maplin.  Below is the finished product:

On the first launch using this new launcher, the rocket went up without a hitch.  Mission accomplished! I don’t plan to stop there, though—the next version will have even more pointless features!

© Cooper for TechRant, 2011. | Permalink | One comment | Add to del.icio.us
Post tags: Electronics, rocket

Minecraft—the sandbox indie game that in the last year has taken the gaming community by storm. It’s not out of the ordinary to hear people who have spent countless hours in the game completely engrossed in their project of recreating the Death Star; known for its freedom to build and create, Minecraft is one of those hits. However, it has had an anything but normal development cycle.

The game began popularity in its earliest stages of development starting in alpha. It’s now (somewhat) regularly updated through patches and new content updates. Latest to hit the game is the 1.8(.1) Adventure Update.

The official trailer from development team Mojang outlines some of its new features and gameplay changes:

The Adventure Update is the second major update to the game—the first being the Halloween Update—and it promises to bring new experiences to the game, with new gameplay changes, mobs to kill, items to craft, and newly restructured world generation to explore. The Adventure Update is further proof that the game is steadily approaching a full release.

My only previous knowledge of what was to be included in 1.8 only spanned  new items, new mobs, and the idea of strongholds and towns. What I discovered is a new game that just may cost me my grades for the semester.

The new world generation restructuring make for some awesome sights!

The new XP system that was introduced is one of the features that most were looking forward to, but for now, it’s useless. The developers have said that the experience you gain from killing mobs will be used to (possibly) level up physical attributes in update 1.9. The XP bar (seen above in my screenshot of an underground chasm) looks to be the one thing that is going to finally give this sandbox of a game some direction. There are countless ways Mojang can implement this in the future, and that’s something fans will be anxious to discover at the future Minecraft Convention, Minecon.

The addition of randomly-generated towns and strongholds are also one of the lead excitement factors for 1.8. In my time, I was able to find one town and convert it for my own use….before being killed and then losing its location in the process, that is. At the time of publication, towns are not populated by their purpose, that being Non-playable Characters; they’re supposedly going to be giving you quests around the world.

Somebody dust them cobwebs!

Strongholds are much, much cooler new structural additions in the update. They are randomly-generated underground structures, filled with all sorts of goodies, from chests of food, to libraries, to rooms covered in cobwebs. They are rare, with only three being generated per world. I have not found one yet, but from the pictures and videos, I can tell that they’d make one cool mansion.

Entrance to a Stronghold

My pitiful excuse for a first night home.

With the addition of hunger to gameplay, food doesn’t replenish your health anymore. Rather, it effects your hunger bar. If you keep this hunger bar nice and filled, then your hearts begin to refill. It mixes up how you deal with damage, now that you have to begin keeping a readily-available stock of food at home base. Remember to cook your food for maximum retention!

NOPE.

Before I wrap things up here, I’d like to touch base on what has become the source of my fear during my evenings: the new Enderman mob shows up at night, with its long legs and arms ready to do you harm. Hovering your “cross marker” on the Enderman will make him notice you. Move it away, and he’s after you, teleporting to get closer and also stealing random blocks along the way. If you’re near some water, jump in for a swim and you’ll be fine. Nothing has got me sitting up in my chair faster than seeing those white eyes staring through a forest.

Naw bro i'm good.

The Adventure Update 1.8 is a healthy dose of new content for Minecraft. In the time since I last played the game, it has grown substantially, and it still retains its reputation of sucking the hours away from its fans. Even though 1.8 has come with its share of ever-present bugs (framerate was game breaking-bad until 1.8.1 was sent out, for instance), it has lived up to the expectations of many. With the addition of new biome restructuring, newly-generated worlds full of new environments, rivers, and canyons await your exploration.

There is much, much more to be seen and I haven’t touched them all (creative mode, server lists, and more, in game content!). So grab onto Notch’s beard and check it out for yourself!

 Sources:

    http://www. Minecraft.net

    http://www.reddit.com/r/Minecraft/comments/kfmva/adventure_update/

    http://www.minecraftwiki.net

    http://www.youtube.com/teammojang

    Google Images search for the Enderman meme photo

© garinrichards for TechRant, 2011. | Permalink | No comment | Add to del.icio.us
Post tags: gaming, minecraft, review

We asked Antony a few questions about himself, his work and his book.

Please introduce yourself in 140 characters or less…

Hi, I’m Antony. I make websites and stuff.

How would you define “front end developer”?

Someone who develops primarily in the context of a web browser.

Your job titles have ranged from Web Developer to CTO, and your specialties are numerous. What area do you enjoy working in the most, and why?

Definitely the front-end stuff—JS, HTML and CSS. I love the instant gratification; we always get the credit when something works well. You only notice the server-side developers when something is broken. I also really get off on the fast pace of it all—things can change so dramatically in a few years, and our industry is really passionate about doing things well.

Rumor has it you made a tweeting doorbell. What inspired that idea?

It’s true. I’d always wanted my doorbell to send me growl notifications, so I’d have a history and would notice someone was at the door even when I was in the garden (or a nearby pub). Then Twitter came along, and it was a logical progression of the idea. Actually, it can be a bit intrusive, and a friend of mine asked me (very fairly), “Don’t you ever want to be left alone?”

What did you do before you became a web developer, and how did you move into that role?

Technical support. My first job, I was fixing everyone else’s computers and didn’t even have my own computer. I slowly put one together out of the parts in the office. I made my own speakers from motherboard speakers and cardboard boxes. I didn’t have a mouse for 6 months. I highly recommend everyone try not having a mouse for a period of time—it forces you to learn all the keyboard shortcuts and makes you super-productive. Anyway, as the company become more successful, we hired more and more technicians, and I became the head technician. Through good delegation I had more and more time on my hands, and the Internet was just taking off, so I built a series of training guides in HTML. Thinking of the kind of code I would have written back then makes me shudder… I was offered a position and training in Lotus Notes, or to move into web development. I am so glad I made the decision I did!

What inspired you to write a book?

The book represents a lot of ideas about CSS and process in web development that reflect the real world, and sensible and pragmatic ways of working. I became frustrated about some of the touchy-feely, awful advice developers were being given, and Yaili and I decided it would be a great project to embark upon.

Can you give us an overview of the chapter you most enjoyed writing?

All of the chapters were great to write—writing about something really tests your knowledge of it—but I think the performance stuff was the most interesting, and easy to implement. I learned a lot myself in the process.

With the recent news we will be seeing more tools to aid debugging of minified JS and the likes of CoffeeScript, are we about to see a rise in the use of pre-processor scripting?

That’s difficult to say. When we talk about a big rise in the uptake of something, we really notice that in start-ups and such—not really in big businesses or very highly-trafficked websites. I’m not a fan of CoffeeScript, but perhaps I’ve not given it a fair go as of yet. I’m loving NodeJS, but it’s so difficult to try everything that’s out there and keep up. Debugging minified JS is so useful, but I’m never going be comfortable working in that kind of code. I think there will always be a place for easy-to-read code, and build scripts.

After reading your book, am I correct in assuming you’re a big fan of LESS / SASS? If so, do you actively use them?

I love the CSS pre-processors. There are some obvious disadvantages to using them, but without going into too much detail, the advantages far outweigh them.

Without being too bitchy, I am no longer a huge fan of LESS, although I was before. During the authoring of that chapter, LESS was moved from being based in Ruby to NodeJS—with no explanation, or changelog, or anything. Most of my code examples were broken, and I had to rewrite that entire section. This prompted me to write a section on how to evaluate third party libraries, of which LESS fails every point. So, maybe it was great fun to code in LESS, I decided it was not something I could recommend for a production environment.

I’ve recently looked at Stylus, which is fast and compiles and minifies really nicely—but the uncompiled code seems very verbose and hard to read. SASS is definitely my favourite – in particular SCSS. I’m not sure why it has less love than LESS, but it’s better-built, more full-featured, and seems to be written by conscientious developers; it passes all the points in my checklist.

Sadly, I’ve not yet come across a SCSS parser for NodeJS so (hypocritically), I am using LESS right now in some projects, but I certainly don’t use it in large production environments.

What would be your advice to those looking into pre-processors Javascript (like CoffeeScript) and CSS (like LESS/SASS)?

There are several important tips here.

1) Know how to do whatever you’re doing as virgin code, as well as via a pre-processor, or you won’t be able to debug it.

2) Understand exactly what the pre-processor is doing, and what the output will be. For example, nested selectors in LESS or SASS are very cool, and feel nice and tidy, but the outputted code is likely to be unnecessarily highly specific and inefficient.

3) Know the disadvantages of using a pre-processor—such as difficulties locating lines and selectors when debugging, etc.

I would also, obviously, recommend you buy our book.

What’s the one debugging tool you can’t live without?

Charles is an absolute lifesaver – especially for fixing bugs on production environments without touching them. I would find it very difficult to do without that now.

People always argue about which browsers’ developer tools they think are best. How do you think the main browsers compare?

Firebug is still the most mature, but it’s not included in Firefox by default so it would seem unfair to attribute that to Mozilla. WebKit’s dev tools are the most feature-rich now (although the UI still seems clunky compared to Firebug), and Chrome has a more frequent release cycle than Safari, so its tools are always the most current. I guess Chrome is the winner.

That said, though, Opera Dragonfly has some really nice features built in, and is under rapid development, so it’s well worth considering, too.

Any other planned Arduino / Twitter projects lined up?

The tweeting doorbell is sadly not an Arduino project. I just found a load of tools that worked really well together and wrote some fancy AppleScript. If you want to see some fancy Arduino work, I’d suggest you check out my friend’s site http://wi-drive.co.uk/, with instructions on how to drive an R/C car from your iPhone!

Out of all the places you’ve previously worked, where do you think you’ve grown the most and why?

Definitely the BBC. Before I worked there, I was under the impression I was an awesome developer with little to learn. Being surrounded by developers that were *actually* awesome showed how wrong I was. I learned an awful lot there, and have been learning ever since.

Have you ever pulled an all-nighter, or early hours on a project? (What was it and why?)

Of course! The one that comes to mind was for a company called AdTool – a deployment was due the next morning and the client was expecting it, or we were in trouble. Unfortunately myself and the other lead developer had deemed it sensible to attend a Christmas party and were a little worse for wear! We did our best, struggling through a drunken haze, trying to type things that made sense, but it just wouldn’t work. We passed out at 6am. When we woke up at 9am, we discovered we had just spelt the password wrong, and we fixed it with 15 minutes to go until the deadline.

What’s the best bit of advice you have ever received?

Clever is not the same as good.

Also, my favourite interview question is “what would you ask you, if you were me?”

What websites do you visit on a daily basis?

The usual suspects… Stack Overflow, digg, MacRumors, Daring Fireball, A List Apart…

I see you’ve spoken at Standards-Next. Will we be seeing any more talks?

I’m interested in doing a talk (and possibly another book) called “How to do SEO without being a ****”. I may suggest this to someone at some point.

Finally…
What are you currently most excited about on the Internet in general?

I am really loving NodeJS and Jade right now, but terrified about the lack of documentation for all of the new initiatives popping up all over the place. Without documentation, it is very difficult for this things to reach highly trafficked websites. But they’re great for playing with.

Anything else you would like to mention?

Thanks very much for reaching out for the interview, and I really hope you’ve enjoyed the book. For anyone based in London, I’d love you to come along to one of our MF Boat meet-ups http://mfbo.at/ (where geeks get drunk on a boat) or to catch up with you at BarCamp or a conference sometime.

Thanks!

Thanks for your time and insight, Antony! We look forward to seeing the reactions you get to this interview.

© Relequestual for TechRant, 2011. | Permalink | No comment | Add to del.icio.us
Post tags: Arduino, browser, css, Development, html, interview, Javascript, NodeJS

Everyone knows that the iPad is taking masses of sales away from PCs in the casual user space, and it won’t be long until the PC is relegated to a solely-enterprise business.

What I’d like to talk about today, though, is a quick anecdote from a small business owner I know. So we’re not talking about the consumer space, here.

The guy I’m talking about owns his own hairdressing salon. He’s been a hairdresser for about 20 years, and the business is doing really well. He’s just expanded his premises into the shop next door and now has a nice medium-sized salon in the centre of our town. Now and again I’ll go in and chat to him about business and how everything’s going. The last time I was there, we got onto the subject of technology (as is generally the case when people talk to me), and he said he was quite interested in getting an iPad for the salon.

My first reaction was, “Why on earth would you want to do that? He then explained that he thought it’d be a nice idea if people, while they’re having their hair done, could ‘like’ the salon’s Facebook page or maybe tweet something complimentary. I then came round to his thinking and thought, “Actually, that’s a pretty good idea.”

People love using iPads—just look in an Apple store next time you’re around one: all the iPads are generally being played with, and you’ll always see the MacBooks looking a bit lonely. So I could definitely see people giving the salon a bit of a social boost if they got to check their Facebook or Twitter while having their hair done. So I commended the salon owner on his idea and offered my services if he needed any help getting things set up.

After this encounter (and after reading Siegler’s post), it occurred to me that it would never have been a good idea if we were talking about a PC. Could you imagine? You’re getting your hair done and somebody slings a laptop onto your…uh…lap, and asks if you want to do a spot of casual computing? It just wouldn’t work.

This brings me round to my real point—OK, so it took a while—which is: for casual users, there is no better PC than the iPad.

PCs are still great work machines, and I can’t see the iPad taking that market any time soon (although watch that space), but when it comes to situations like the one I detailed above, the iPad makes computing fun for those who think computing is a pain, and that’s why the days of the consumer PC are numbered.

© IanKent for TechRant, 2011. | Permalink | No comment | Add to del.icio.us
Post tags: iPad, pc

Basically, it’s all about Near Field Communication (NFC) and smartphones—don’t worry; all will be revealed, and it’s very simple. If people keep buying smartphones this could, in theory, revolutionise how we pay for anything and everything. Recent figures of smartphone usage in the UK (according to this Ofcom report) show that over a quarter of adults, and nearly half of all teens, now own a smartphone. Here’s a taster of what’s in store…

So, time saver or money-waster? Changing technology for the sake of change? Too confusing? Do you even own a smartphone?! Leave us a comment, we want to hear your views on this!

View the original post on Daily Infographic. 

To find out more about NFC check out this Wikipedia page.

© Haz for TechRant, 2011. | Permalink | One comment | Add to del.icio.us
Post tags: infographic, near field communication, nfc, smartphones, wallet

It’s extremely clear to me that the authors of this book, Antony Kennedy and Inayaili de Leon, are highly experienced and know what they are talking about. They are professionals at the top of the game. Further, being published by Apress indicates that this is a quality technical book.

Antony has worked for the BBC, BSkyB, Tesco, Disney, and Channel4 (among others). Employed as a web developer to CTO to Head of Front End Development, Antony has worked at all levels. This gives him real insight into how anyone working with CSS can help the team work as a well-oiled machine. You can find him on twitter @booshtukka.

Inayaili currently works for Canonical, the organisation behind Ubuntu, takes on freelance work, speaks at a number of events and also writes for the likes of 24 ways and Smashing Magazine. She also writes on her own blog, Web Designers Notebook (which is part of the Smashing Network), on and around the areas of web design. Find her on twitter @yaili.

Assuming you’re interested in finding out more about Antony and Inayaili while the giveaway is running, I’ll be interviewing them both and updating this posts with the links.

Just as with the last book giveaway, here’s the table of contents I pinched from Amazon…

1. The Value of Process
2. CSS Style Guide
3. Fundamentals
4. Frameworks and Integration
5. Brand Implementation
6. CSS and Accessibility
7. Devices
8. Performance
9. Dynamic CSS
10. Testing and Debugging
11. Creating your CSS
12. Appendix 1: CSS Standards Guide
13. Appendix 2: Accessibility Guidelines
14. Appendix 3: Browser Support Guidelines
15. Appendix 4: Development Process

If you’re not already convinced that you need this book, check out the Amazon page.

Some have said they have had issues entering. You will need Javascript enabled, and the giveaway widget will load to the right of the image. It may take some time, so be patient. Any problems, let us know via twitter.

© Relequestual for TechRant, 2011. | Permalink | 25 comments | Add to del.icio.us
Post tags: book, css, design, Development, interview