Is read the book, and then write a review of it on your blog.
And I’m not asking you to write a good (or biased) review either. I’m just asking for some feedback. I’ve had a couple of people already writing reviews on their blogs, Google+ and Amazon, but more the merrier. And I want to know what YOU think!
For those who haven’t seen my previous blog post about having published this book, this is my first ever book, and while I have written hundreds of technical articles, none of them have actually made this far on the “publishing chain”.
And this is why I want to have all the feedback I can get. Again, YOU are the sort of person who buys the sort of books I write, and it’s YOU I wanna hear from.
There are 5 free e-copies up for grabs, and I’ll give it away to the first 5 people who show interest in reading and reviewing my book.
Well, that’s gotta save you some money eh?
So get in touch by leaving a comment to this post, or via contact form with your name and blog URL. I’ll then get you your free copy, and all I ask in return is to be notified when you’ve published your review.
Installing everything was painless, but I have to admit getting NodeJS to build on a Raspberry PI wasn’t the most straight forward thing I’ve ever done. Not because it wouldn’t work, but because building it from source took forever. Just to clarify, I didn’t need to run it on a Raspberry PI, but just wanted to prove myself I could. This mini project had 5 elements to it:
Three from which you don’t even need to install (as they are npm modules). Just by adding them as dependencies on the package.js file, they get installed into your project, so deploying is made easier (in theory), as you don’t actually need to install anything other than NodeJS.
Now you might be asking yourself why I say “in theory” when taking about deployment. The fact is that deploying a NodeJS application is a pain, since all you end up doing is making [your preferred webserver here] proxy all the calls to your local application. Why? you may be asking…
The fact that each NodeJS application you create establishes its own server, means anything will clash with your already installed webserver, since you can only have one webserver per TCP port. So if you want to host all your applications as well as any new node project you come up with, then you will end up taking this route. It’s not terrible, but just means you now need to support yet another thing. There are tools out there to help you with such thing, but let’s not digress.
Building the application was fairly painless, and using Jade was the big highlight for me. For a while now I had looked into templating engines, and really wanted to delve into it a little more. I had previously looked at jQuery Templates, Ext and Dust.js, but Jade is totally different, in a way that actually pleases the eyes (except when it doesn’t :-)).
Did I become a NodeJs expert? No way!
Will I keep looking and building sexy applications with it? Heck yeah!
A few months ago I was contacted by Packt Publishing about a new project they had in mind and thought I’d be a good fit for.
The challenge was to write a book about one single topic that would enable readers to learn and become proficient on that topic in about an afternoon.
Anything with 200 pages would be too much, so I had to keep the book very lean while keeping the reader interested, and giving her enough ground to be able to build a final project just with the information contained on the book.
While the article was only about dragging and dropping DOM elements, I was asked to write a book on how to drag entire layouts on the screen, and allow users to fully customize their experience.
I set off by providing the publishers with a proposal of what I thought the structure of the book should be, and decided to use Gridster as the plugin for drag and drop.
If you haven’t heard about Gridster, it’s a very nifty jQuery plugin that allows you to do layout drag and dropping, and has lots of cool API functionalities embedded in it that allow you total control over your layout’s mobility, and immediate feedback on all your elements.
On the book, I take the reader through the whole process of downloading and adding the library to their website, until the point they can actually create a fully functional metro styled layout that allows users to drag and change positions on every item on the screen.
At work, we use Apache JMeter for load testing applications or API’s we build.
JMeter is an amazing open source tool with an even more amazing community behind it, so if you’ve never used it, you surely are missing on a great piece of software.
Anyway, one thing that used to annoy me a bit, was the fact that when creating tests for API’s, I’d sometimes need to pass in dates.
So imagine the following case:
You’re testing that your API can create a new book in your bookstore for a specified date, but the business rules imply that you can only create a new book with a release date in the future.
If I had hard coded this to a date in the near future, I would then need to update it at some point as to always make sure my dates really were in the future.
I could also put a date very far in the future, but my business rules again dictate that I can only pass in dates up to 60 days in advance, so I’d end up having to update my tests in about two months or so.
Come the user defined variables:
The code for your user defined variable would look like this:
What it does is simply create a new date, add 60 days to it, and then format it as “yyyy-mm-dd”. You could change the number of days and format easily by moving things around.
A sample request would then look something like this:
I’ve been asked to come up with an image slider prototype for something new we were doing at work.
I would generally just find a suitable sliding jQuery plug-in and get the developers to use it. However, this time, there were two very peculiar requirements necessary for this slider (hence why I was asked to prototype it)
The image slider should only display the next and previous arrow when there was something to display. It should hide the arrows if it didn’t have a next or a previous item to display.
Ordinarily image sliders are infinite, which means you can keep clicking next forever, and it will always loop through the images. This alone negates the requirement above, since you always have a previous and a next image. So I had to somehow limit the image slider to only go up to the last image when clicking forward, and stop at the first image when rewinding.
I looked at a few options for this, but most of the image sliders out there seem to not allow you to have full control over the display of the arrows, or to make it stop when it reaches the last images. Also, most of them seem to only open up in a light boxes, which makes it less ideal when you don’t want to distract your users off the main objective of the website (don’t get me wrong though, light boxes are cool, but they have their time and place).
I then came across to Nivo Slider(http://nivo.dev7studios.com/), which claims to be the “The world’s most awesome jQuery & WordPress Image Slider”. I can’t really comment on that statement, but I can tell you they’re pretty good, and have lots of different options for you to use in your image sliders, as well as allowing various transitions between each slide.
Implementing it was very straightforward, as all you need to do is import their css, chose a css theme and the plug-in itself (I’ll assume you already have jQuery installed)
My code then ended up looking like this:
The code above will pretty much get you going, and your images should now load nicely on the screen, and you should be able to slide through them.
However, when you do it, you will notice none of the requirements mentioned above have been fulfilled, since you ended up with an image slider.
To get the arrows to show and hide dynamically, I did a bit of research and found someone doing that exact same thing. So it was just a matter of adding that to my code, and attaching it to the “afterChange” event, which will get called every time you click through any of the arrows.
I then added it to my configuration as such:
You will have noticed this only disables the arrows after you change the slides, so you’re still faced with the problem that you load the page displaying the two arrows. In order to remove the arrow from the left (I don’t need a left arrow if I just loaded the page, since I have nothing to go back to), I simply used the event “afterLoad”, which runs as soon as the object is added to the DOM.
So the first requirement is fulfilled:
The image slider should only display the next and previous arrow when there was something to display. Check
It should hide the arrows if it didn’t have a next or a previous item to display. Check
The good news here, is that by doing this, I have automatically satisfied my second requirement, which was to make sure the user couldn’t loop through to the first image when she reached the last image. By removing the arrows when necessary, I am able to stop the user from ever going back to the first image without going through the previous images.
because I was using “slide in” transitions, one thing I found to be a bit annoying, is that you can only define one kind of transition per slide, so when sliding in an image, you normally slide it in from left to right. If you want to slide it out (i.e. by clicking on the right arrow), you’d normally expect the image to disappear from right to left, as if it was leaving the screen.