Pretty excited. I heard about node.js about two years at Web Directions South. It was just starting to get coverage and a very small group of supporter were excited. The excitement in me died prematurely as I realised at that time hosting of node.js was going to a be pain. Now times have changed and it looks like everyone is into node.js. This weekend I am going to start learning it by reading the book Jump Start Node.js by Don Nguyen, on SitePoint. I will post a follow-up to what I think of the book.
From chapter 1, node.js:
- Is fast – really fast
- Works on both the front and back-end
- Is non-blocking
- Theoretically will scale beyond your operating system
- Is event driven
- Can be accessed in Command line / Terminal RPEL
- With Express a quick app is built
- MongoDB is used for a signin form
It is a great start to node.js. You get a feel that it is something that is complex, but has a lot of upside. Obviously the ‘Hello World’ app is super complex compare to PHP’s. Though I would say the abstraction of the server is why PHP’s one is so simple. You see that the author has missed using sudo when running one of the commands, and some of the steps are hidden in the middle of a big text-block. It is a good start just a few small sloppy errors. All in all I am excited to get started with node.js.
Here it is, an ad for a front-end developer/designer on Seek.
Since putting up the ad we have received some brillant and some terrible resumes.
This has lead me to think that web developers need some guidelines when they are seeking a new job.
- You must have a personal site. This is critical, you are a web-head, you advocate the web, you love the web, I expect you to have a website. This does not have to be the world’s most mind blowing site. Just something that is going to show you can at least put some code together. If you are a hardcode developer and cannot design than use Twitter BootStrap, at least it will look neat. If you are a designer than the site needs to look awesome!
- If the job is for UX/UI your resume must reflect this, even if it isn’t, you are a tech-head so it should show a logical organisation. DO NOT USE THE STANDARD WORD TEMPLATES!!! They are horrible and lead to a bad user experience.
- Explain your role on projects. Do not list one of the world’s largest sites with a vague one word description of your role. Clarify exactly what you did. Otherwise there is no way of knowing if you were the UX lead who designed the end-to-end customer experience or the tea-lady.
- Do not list your ex-company’s projects unless you were on them, and if you were on them, list what your role and accomplishments were.
- DO NOT CLAIM OTHERS’ WORK AS YOURS. Are you serious? Do you honestly think that you will not be caught out? Come on! If you do not get caught in the interview process, you will be caught out once you start and your new employers will be very upset. Though I get the feeling if you are in this group you are like one of the applicants who’s code samples still contained the original author’s links in the footer.
- This is professional process, so treat it as such. While you can be quirky and this is encouraged, do not put not safe for work content in your resume. Check your spelling. Consistently format your resume. Write a cover letter covering each of the requirements. Write a two to three sentence introduction in the email.
- Make me want to hire you. You are a product, you need to make me want to spend money on you. Tell me about how you will make us successful, especially when I put exactly how you will in the job ad.
- Provide samples of your work. These can be code samples, wireframes, mockups, GitHub, your blog posts, side projects, StackOverFlow responses, Redit etc. as long as you created it. Given the fact it is so easy to create side-projects online there is zero reasons for not having something you created.
- Do not apply for roles above your experience level. If you are straight out of uni you will do well, just don’t apply for a role which is requiring you take on responsibility beyond your ability (there is of course exceptions). There is plenty of opportunity to jump in the deep-end. Just get some experience first.
Basic hashing of passwords is poor. LinkedIn should have expected that one day that their password list would be stolen and when that happened it should have been hashed better so a standard dictionary could not reverse the passwords. Tthe LinkedIn passwords were leaked all over internet and with the help of crowd-sourced hackers the passwords were easily reversed back from SHA-1 hashes substrings to the plain text passwords. With tools like John the Ripper social hackers like Francois Pesce was able to reverse over 2 million LinkedIn passwords.
Continue reading “Password Hashing – With some smart salt”