Due to the ever-growing popularity of React, Facebook’s user interface library, there has been some discussion on the topic of CSS and whether or not it has a future in its current form — that is, in the form of declarations in a separate stylesheet that provide presentation information for a given page or section of markup.

I’m not going to rehash the conversation or the pros and cons here. For those not familiar, here are a few links you can check out:

• The Debate Around “Do We Even Need CSS Anymore?” by Chris Coyier
• React: CSS in JS slides and video presentation

But what I will do is provide some strong evidence that CSS is alive and well.

When I read the reactions and heated debates in comment sections of articles like this one or this one, two things become clear:

• Developers are passionate about CSS
• Developers are not happy with some of the proposed solutions for large CSS projects

The two links in the second bullet point in the introduction above are a slide deck and video presentation by Christopher Chedeau, a developer working for Facebook on the React project. This past week was the first time I tried delving into React a little bit, thanks to this great tutorial by Shu Uesegi. After that simple introduction, the slides gave me a little more context.

Christopher addresses 7 CSS architecture problems that he believes can be solved by using JavaScript to manage and implement styles. This is the kind of thing that makes a lot of purists shudder because, with React, you’re basically writing your markup and styles in your JavaScript — something that’s usually discouraged in keeping with “separation of concerns”.

The screenshot below captures one of Christopher’s pertinent slides in this regard, outlining the 7 problems that React attempts to address:

Christopher makes a great case for solving CSS’s problems in JavaScript, so I highly recommend you keep an open mind and check out his slide deck (although I’ll forgive him for saying that w3schools is his favorite website for learning JavaScript!).

So it’s clear that it feels like a CSS revolution is needed and some might say it’s already under way. But it’s also clear that CSS in its current form is not going away anytime soon.

If you were keeping tabs on your RSS feeds and Twitter stream in the past week or so, then you probably came across my most recent CSS article. That was one of the most enjoyable articles to write, and judging by the incredible response in the comments and on social media, I’m glad to see that it was as enjoyable for readers.

[caption id="attachment_110386" align="aligncenter" width="800"] Artwork by SitePoint/Natalia Balska.[/caption]

The popularity of those types of articles demonstrates that developers still love CSS in its traditional form. Tweets by Ilya Grigorik, Smashing Magazine, CSS-Tricks, and others were shared and favorited hundreds of times. And the traffic to that article and its predecessor has been amazing.

The content in my articles is mostly covering stuff that’s been available in browsers for years, not just the new “CSS3” features. In fact, I intentionally tried to use as many cross-browser CSS tips as possible and the response has been overwhelming.

But this sort of thing is not unique to my article. Consider past CSS articles on other sites that have been hot in the community. Two that immediately come to mind are, not coincidentally, both by Heydon Pickering:

• Tetris and the Power of CSS
• Quantity Queries for CSS

Continue reading %CSS is Alive and Well%

We interact with web pages every day. On the low level, clicking on various HTML elements or entering text in text forms using input devices. What's the higher-level purpose of doing those things? It's trying to get something done. Completing a Google search, submitting a contact form, or rating something. The Page Object pattern is a great, object-oriented way to keep your code clean while accomplishing those higher-level things as your application grows.

Why use the Page Object pattern? Two words: code reuse. Let me explain.

Suppose you're making an application that will go to a search engine and perform a search using a particular phrase. To do this, you will need to:

• Go to the web page
• Locate the HTML element where you can input text and enter your keyword (the text box)
• Find the Search button and click it

Continue reading %Model Web Pages with the Page Object Pattern%

Here's a familiar sounding story:

A new 'technology' comes along and is initially dominated by a small clique of 'in-the-know', mostly male, often bearded, 'tech geeks'.

Quite soon that 'technology' goes mainstream and is adopted by women and men, young and old, families, couples and single for all sorts of new and innovative needs.

And then some of those original guys get a bit grumpy because things aren't like they were in the good ol' days™.

And some of them behave badly.

Sound familiar?

Gamers? Programmers?

No. I'm talking about....

Looking back now, it's impossible for us to understand the sense of gobsmacked wonder that the invention of the telegraph caused in the mid 1800s.

At a time when the word 'technology' meant 'steam-powered', the concept of invisibly, instantaneously communicating across hundreds of miles was indistinguishable from pure magic.

[caption id="attachment_111053" align="alignright" width="198"] Samuel Morse: 1850's Tech Hipster? [/caption]

But as any successful tech tends to do, the user base expanded quickly in both size and diversity.

And since operating a telegraph machine was a learnable skill where size and strength were no real benefit, it was a job that attracted a lot of young, smart, single, often working-class women.

This meant that many early city telegraph services became the first offices staffed by a predominantly female, technically-literate information workers.

This had some interesting flow on effects.

Firstly, companies were happy to employ women – they were paid less – but generally pressured them to resign when they married. This 'woman's place is in the home' idea got a lot of momentum as former Civil War soldiers began returning to the workforce.

There is no doubt that many 1800's men were threatened by the concept of women that weren't financially reliant on a father or husband. This fear played out in many ways.

Some lashed out petulantly. Male telegrapher would transmit profanities over the wires designed to make female operators feel uncomfortable. In 1875 the Chicago Western Union office dismissed operator Ed Agnell after listening in on his expletive-laced transmissions to other offices.

Others spread rumour and innuendo about the 'immoral conduct' of female co-workers - a particularly devastating attack in the era of Victorian social values.

Women were also excluded from union membership for many years. At an 1865 vote to admit women to the National Telegraphic Union, the Boston delegate, a Mr. Stover claimed

..as operators they (women) are no honor to the profession. ... the result is constantly making blunders to such an extent that I know every telegraphic superintendent .. are weeding them out. I trust we shall do nothing to bring them into the union'.

When immediately rebuked by conference organisers, Mr. Stover went on to assert that while there were a very small number of good female telegraph operators, the business skills required to achieve this level of proficiency were not proper "womanly" behavior, and inferred that any women that DID succeed must not be a proper woman.

What a charming fellow. *sigh*

Again he was strongly rebuked by both men and women, but we'd have to believe Stover wasn't alone in his views.

There were also genuine arguments put forward that the telegraph was leading to the moral downfall of society. Letters to newspapers warned that poor, innocent, young women risked being tricked into marrying scoundrels and villains over the telegraph wire.

I didn't say it was a plausible argument – but that's what they claimed.

Regardless of this ever-present threat of malevolent marriage, women didn't seem to be discouraged from entering the industry. By 1920 there were nearly 17,000 women telegrapher working across the US, making it the third most common employment (behind domestic services and teaching).

There was also a certain amount of awe and fascination for those who 'controlled the wires' so telegraph operators took up an important place in the pop culture of the late 1800s.

[caption id="attachment_111054" align="alignright" width="200"] Railway Stories: The 'Girl Op' [/caption]

The telegraph office provided daily opportunities for an eligible young bachelorette to come into contact with young businessmen, and dime store novels often centered around the adventures of sassy, modern 'girl ops'.

In 1880, Ella Cheever Thayer, a working telegrapher, published what must be the first novel concerning a cyber-romance - 'Wired Love' is the story of two telegraphers who fall in love without ever meeting in real life.

So what can we take from all that?

Perhaps I'll just finish with the words of Lewis H. Smith, the editor of the NTU's Telegrapher periodical magazine in 1865 and a very progressive fellow for his time:

"If men and women could change places, how think you the former would come out? If we were hampered and excluded as women have been for centuries, where would be our boasted superiority?"

Smith attracted flak from the NTU rank and file for his position, but never backed away from them.

So, here's a salute to the eloquent voice of Mr. Lewis H. Smith! And another to all Lewises since.

Continue reading %Dots, Dashes and Dudes Behaving Badly%

If your initial reaction to the title of this article was something like WHAT?, I want to reassure you. You don’t have to take my word for it! What I’m going to do is to show you how to build a fine piece of software that can run on multiple operating systems, interact with them and present the results in a pleasant way. The whole task will be achieved by using JavaScript and a small amount of bash/powershell commands.

Said that, you might be wondering why I want to make this experiment. It might come as a surprise, but “winter nights are long and lonely and I needed something to kill some time” is not the answer to this question. Maybe something on the line of “I wanted to refine my skills and master JS” would be closer.

Although this project does not carry a hight value on itself, my humble opinion is that it will:

• provide you the skills (and some basic design) to build a RESTful service and any interface you’d like for your favourite OS
• let you focus on cross-OS compatibility
• introduce you to valuable design patterns for JavaScript and useful Node.js modules.

With this in mind, let’s start talking about the server. What we need is to create a (RESTful) service that provides us, in real-time, the last readings from our OS.

The answer to these two smart questions is simple. Firstly, we need a server because, for security reasons, there is no way a browser would allow you to execute a command on the OS (I bet you wouldn’t be too happy if any creepy website was able to erase all your files, would you?). Secondly, we'll have a RESTful service because there are several advantages in using REST interfaces. This is out of our scope, but I’ll point interested readers to a few good resources to learn more about this topic at the end of this article.

Now, what we want is at least one endpoint that can be called from any service over the HTTP protocol, hence decoupled from the actual representation of the data it'll provide, and in response sends data back to the caller.

To send this data back, we’ll certainly need to agree on a format. We could send back some raw text and leave parsing to the client or, as an alternative, we could send structured data (using XML for instance). I ended up choosing JSON. The reason is that we'll have structured data but far less redundant than XML. Note that by agreeing on a format for the data we introduce a certain coupling for the client, that now has to adhere to our formatting. Nevertheless, this choice gets several advantages:

• We can specify the format as part of our interface: clients naturally have to adhere to APIs of any service they use (for instance, the name of the methods or the endpoint exposed) and as long as we don’t change the format, there will be no difference. Obviously we should still think this format through before hitting version 1. In fact, we should (almost) never change a public interface in order to avoid that clients will be broken.
• We would sensibly slow down clients by delegating parsing to them.
• We gain decoupling from different OSs by providing a common format for all of them. To support a new OS, all we need is an adapter for the data we receive from it.

At this point, we need to start talking about how and where we’ll get the data we send to the client. This is maybe the trickiest part of the game, but luckily there are plenty of modules for Node.js that allow our server to talk to our OS, and even understand which OS is running on our machine.

Continue reading %Creating a Battery viz Using Node.js: Getting Started and Server%

Local notifications let an application inform its users that it has something for them. For example, a reminder or an new item for sale while the application isn’t running in the foreground. Local notifications are considered the best way by which an app can communicate with its user, even if the user is not actively using the app.

In this tutorial I will show you how to trigger local notifications in a cordova based app. I will explain how local notification work, how they differ from push notifications and the APIs provided by the Cordova Local-Notification Plugin to trigger local notifications. I will create a basic Reminder app to show how to use the Cordova Local-Notification plugin in a real world project.

Continue reading %Integrating Local Notifications in Cordova Apps%

Everyone wants to be unique. I guess you won’t be super happy if in your surroundings there are many people looking just like you, right? This holds true for the other people too. Your friends also won’t be happy to see clones of you everywhere. The same is true for our websites.

Nowadays, building a website with a front-end framework is common. The problem though is that many people blame such frameworks for making all websites “look the same”. But the tool isn’t to blame if developers aren’t willing to make the necessary customizations.

For those of you who want the websites you build to stand out from the crowd, I’ll demonstrate how you can use UIkit’s Customizer to create different themes and theme variations (styles). The process is straightforward, but you need a proper workflow to do it with a minimum amount of headache.

Let’s say that you want to create a dark theme for your website with orange as an accent color. Also, you want two more variations of that theme with blue and green accent colors. Let’s see how we can do it. (Note: For the sake of brevity, I’ll use only buttons to demonstrate the process).

We’ll need to start with ensuring the following steps are complete:

• Download or clone the UIkit repository.
• Install Node and Gulp, if you don’t have them already.
• Install UIkit’s development dependencies. You can do this by navigating to the UIkit root directory and running npm install from the terminal.

When all of this is set up correctly, we can start creating our theme.

Still in the root directory, create a folder called “custom”. In that folder, create another one called “dark” and inside it create a file called uikit.less. Open the file and add the following:

[code language="sass"]
@import "../../src/less/uikit.less";
@import "button.less";
[/code]

The first line will get all Less files from the core framework and the second line will import the file you’re going to use to modify the default UIkit buttons. Save and close the file and create the aforementioned button.less file in the same directory.

Before making any further customizations, you need to make your theme available locally in the Customizer. To do so, in the UIkit root directory, run the following in the terminal:

[code language="bash"]
gulp indexthemes
[/code]

Now launch your local copy of the UIkit website (the one you installed) and click “Customizer” in the navigation bar. When you open the “Select a theme” drop-down list you should see “Dark” at the end of it. At this point, when you select it, you’ll see that there is no styling. Why not? Let’s see.

One thing not mentioned in UIkit’s documentation and which can cost you a lot of headache, is that your theme needs a file called uikit-customizer.less. Create the file and add the following line:

[code language="sass"]
@import "uikit.less"
[/code]

You must put that file, with the above line, in the theme’s root directory (inside the “dark” folder, in our case). If this file is not present, you can’t use the Customizer properly – the theme’s name will appear in the list, but the styles will be missing.

Note: As a rule of thumb, the uikit-customizer.less file should import all files that your theme uses. In our example, importing uikit.less meets this requirement because it includes both the default UIkit styles and your custom button styles.

After adding the uikit-customizer.less file, you will see that this time all components are properly styled. So, we’re ready to move on.

In the component’s drop-down list, placed at the top left corner of the panel on the right side of the Customizer, switch to “Button”. This way you’ll be able to see all available button styles. Now we can open the button.less file and start adding our modifications:

[code language="sass"]
@button-color: #f90;
@button-hover-color: fade(@button-color, 75%);
@button-active-color: @button-color;

@button-background: #000;
@button-hover-background: lighten(@button-background, 20%);
@button-active-background: @button-hover-background;
[/code]

In the above code we’ve modified the variables for the default button’s text and background colors in their normal, hovered, and active states. For other specific buttons, we need to change those variables too:

[code language="sass"]
@button-primary-color: darken(@button-primary-background, 20%);
@button-success-color: darken(@button-success-background, 20%);
@button-danger-color: darken(@button-danger-background, 20%);

@button-primary-hover-color: fade(@button-primary-color, 75%);
@button-success-hover-color: fade(@button-success-color, 75%);
@button-danger-hover-color: fade(@button-danger-color, 75%);

@button-primary-active-color: lighten(@button-primary-color, 35%);
@button-success-active-color: lighten(@button-success-color, 35%);
@button-danger-active-color: lighten(@button-danger-color, 35%);
[/code]

Modifying UIkit’s variables is the easiest way to change the appearance of the framework’s components when dealing with simple modifications. But for more complex customizations, such as adding new rules and/or changing the existing ones without breaking the core, UIkit provides a special mechanism. It uses hooks to safely append your changes. Let’s see this in action. Put the following code below the variables, inside the button.less file:

[code language="sass"]
.hook-button() {
border-radius: 5px 15px;
box-shadow: 2px 2px;
}
[/code]

Here, the hook for the button component is used to add a border radius and a drop-shadow effect.

For even more specific changes, UIkit provides miscellaneous hooks. Each component has such a hook. This is useful for creating new selectors or modifying the ones that have neither a variable nor a hook available for customization. Let’s demonstrate this by adding the following code:

Continue reading %Creating a Custom UIkit Theme with Gulp and Less%

Jetpack is a popular WordPress plugin created by Automattic, the people behind WordPress.com. The plugin brings many of the most powerful features available on WordPress.com to self-hosted WordPress sites, and thereby contributing greatly to the improvement of WordPress powered blogs and websites.

In this article, I'm going to share five great features of the Jetpack plugin that you may not know about, including how to enable, configure, and use them on your WordPress site.

Editing the core CSS files of a WordPress theme is rarely the best approach to modifying, or customizing a WordPress theme. Mistakes can be made which damage the theme, and customizations can be lost if the theme is updated.

With the Jetpack Custom CSS feature, editing, modifying, and customizing can be done without laying a single finger on the theme's core CSS files. If mistakes are made, they can be corrected easily. Revisions can be done faster, and restoring the CSS back to default will not be a problem either!

Continue reading %5 Things You May Not Know about Jetpack for WordPress%

They said they’d be dead. Gone from our docks and into our browsers. The demise of the desktop apps has long been predicted in favor of browser-based models. But with services such as Slack, Sunrise and Quip all going desktop, can we stop writing the eulogies for native apps after all? The demise of the […]

Continue reading %Should You Develop a Desktop or Web App?%

In this video, I'll use Chrome Developer Tools to take a look under the hood of a website, inspecting the individual network requests that are responsible for the content of the page.

Continue reading %Video: Inspecting Network Requests with Chrome Dev Tools%

When I began working on this article, I intended to focus on crime reporting apps. But I found it impossible to remove crime from the society it's part of. I decided to look at a broader scope which covered police surveillance, neighborhood watch, human rights abuses, child sex trafficking and how mobile phone apps can record and report these crimes.

Mother Jones did a report of 13 killings by police captured on camera, that included six fatal shootings captured by bystanders using mobile phones. As the article demonstrates, these apps can be more contentious than first appears. Here's some thoughts on things to consider when developing a social based app.

Continue reading %7 Tips to Consider when Creating a Social Action App%

We know you need content to keep you at the top of your game. You’re not a beginner anymore, but that doesn’t mean you’re not still learning every single day.

Today, we’re proud to announce SitePoint Premium, a membership subscription for web developers. It’s everything you love about SitePoint, plus:

• Access to the full library of SitePoint ebooks
• Hundreds of videos on topics like HTML media, Swift, React, Git, and Ruby.
• The entire library of A Book Apart and UX Mastery titles
• Exclusive Q&A sessions with the best developers in the business
• To celebrate, we’re giving away a free t-shirt to the first 1000 people who sign up for SitePoint Premium.

If you’re a regular SitePoint reader, you might have seen promotions for Learnable, our online learning platform. As SitePoint grows, we’ve decided to bring Learnable under the SitePoint umbrella and expand our community.

Current Learnable members have full access to SitePoint Premium, as well as to the rest of the growing SitePoint community.

We’re so proud of what SitePoint’s hundreds of contributors are building. What do you think? What else would you like us to create?

Continue reading %Big News: Introducing SitePoint Premium%

In this tutorial, we’re going to explore the underlying fundamentals of the popular MV* framework, Backbone.js. We’ll take a look at models, views, collections, and templates, and see how each builds off of each other when building an application. We will also touch on responsibilities and separation of concerns, ultimately paving the way for us to build a scalable application with a sane code base.

Backbone only has one hard dependency, which is Underscore.js. We will also leverage jQuery for easy DOM manipulation. Your typical document structure should look like this:

[code language="js"]

app content here

[/code]

All app scripts must be included after the various libraries. Other than that, we’re ready to dive in!

Backbone falls under the umbrella of MV* frameworks, which means that it is primarily composed of Models and Views. Traditional MVC frameworks contain that extra C, which stands for controller. Historically, a controller would respond to some kind of user input, and communicate that input to the model, or back to the view. In MV frameworks like Backbone, though, the controller logic is handled inside the view itself. To understand a bit more about the anatomy of a JavaScript MV* framework, check out this post.

We’ve jumped the gun a bit here though, as we haven’t looked at what models and views are. Well, it’s not that complicated! I try to think of models as a “model of data”, the same way an architect might have a model of a house, or an engineer might have a model of an aerofoil. With this in mind, it’s easier to understand how a particular model is a representation of a certain set of data. In a production grade application, that data is likely stored in a database somewhere. Models can thus communicate with that database, and perform certain actions, such as CRUD operations.

What about views? Given the name “view”, it’s pretty easy to draw assumptions about the responsibility of views. If you thought that it was to render data for the end user, then you’re mostly correct. Views are indeed responsible for this. In Backbone, however, they house one other major function as I mentioned before. They handle the controller logic. In the second part of this series, I’ll get into event handling inside the view, communicating with the model, and then sending updates back to the view. For now though, it’s just important to understand that this logic does indeed exist, but resides inside the view. Let’s jump into models, and gain a better understanding of them.

Here’s a little excerpt from the Backbone docs on models:

Models are the heart of any JavaScript application, containing the interactive data as well as a large part of the logic surrounding it: conversions, validations, computed properties, and access control.

With that in mind, let’s draft up a little example that we’ll use going forward. Imagine we’re running a surf shop, and we want to build a database of surfboards that we carry. That way, if a customer asks if we have a board from a particular manufacturer, or an exact model of board, or both, we can do a quick look up. Let’s also assume that we want to keep track of the stock. Our model hierarchy would look like this:

[code language="bash"]
Surfboard
|__manufacturer
|__model
|__stock
[/code]

In Backbone, we create a new model by extending Backbone.Model like this:

[code language="js"]
var Surfboard = Backbone.Model.extend({

});
[/code]

Now, we can create a new instance of this model using the constructor like this:

[code language="js"]
var board1 = new Surfboard({
manufacturer: 'Channel Islands',
model: 'Whip',
stock: 12
});
[/code]

The variable board1 now references a new instance of our Surfboard model, and contains its own set of values. As it stands though, we can pass in any values. Let’s make use of the defaults function to add some default attributes to our model. Now, it should look like this:

[code language="js"]
var Surfboard = Backbone.Model.extend({
defaults: {
manufacturer: '',
model: '',
stock: 0
}
});
[/code]

If we wanted to fetch some data from that instance, we would use get, which gets the current value of an attribute from a model. Imagine we had this markup in our document:

[code language="js"]

[/code]

We’re able to populate those fields like this:

[code language="js"]
$('#board1-manufacturer').html(board1.get('manufacturer'));
$('#board1-model').html(board1.get('model'));
$('#board1-stock').html(board1.get('stock'));
[/code]

Continue reading %Backbone.js Basics: Models, Views, Collections and Templates%

In this video I'll explain the differences between CSS and SCSS in Sass.

Continue reading %Video: Sass vs SCSS%

An editorial calendar is the foundation of strategic blogging. It enables you to plan ahead, and if implemented properly should go a surprisingly long way in terms of engaging your audience and growing your subscriber base.

Really, at the end of the day, an editorial calendar is nothing more than a schedule. Think of it like a plan, or a timetable, or a program for your blog posts. You can use it to plot out what your next month’s worth of blog posts might look like. It can helps you determine what you need to write about, how much you need to write, and where the holes or gaps in your editorial schedule might be.

Using an editorial calendar allows you to:

• Hone your forward planning: you can see, at a glance, what you should be writing about, and where your gaps might be. This allows you to easily schedule writing time into your diary.
• Stave off writers’ block: I don’t know about you, but for me, the hardest part of writing is often coming up with a relevant, meaningful, engaging topic. If you have already sat down, and done this, populating your editorial calendar in advance, then when it comes time to write, you can do just that: write.
• Go in deep: creating an editorial calendar makes you take a step back, and approach your blog from a more holistic perspective. It makes you think about your content as a whole, rather than self-contained, compartmentalised, individual posts. It allows you to approach a topic in stages, building out a series of posts to cover a specific topic more deeply; ultimately, it allows you to provide more value to your readers.
• Capitalise on SEO benefit: rather than pluck a topic at random and dash off a quick post to keep tempo with your weekly/daily/monthly posting schedule, creating an editorial calendar makes you slow down, and select more considered topics on which to write. Keyword research should part a major role in any editorial planning process. Use the keywords for which people are searching in your blog titles, headings, copy, and meta-descriptions.

Continue reading %Choosing the Right WordPress Editorial Calendar Plugin%

• SparkFun Inventors Kit - This is the kit that started it all for me years ago! It comes with a range of standard components like colored LED lights, sensors, buttons, a motor, a tiny speaker and more. It also comes with a guide and sample projects you can use to build your skills. You can find it here - SparkFun Inventor's Kit.
• Freetronics Experimenter's Kit for Arduino - This kit is by an Australian based company called Freetonics. It has very similar components to the SparkFun one, with a few small differences. It also has its own guide with sample projects to try as well. For those based in Australia, these kits and other Freetronics parts are available at Jaycar. You can also order it online here: Freetronics Experimenter's Kit.
• Seeed Studio ARDX starter kit - Seeed Studio have their own starter kit too which is also very similar to the SparkFun and Freetronics ones. It has its own guide and such too! You can find it here - ARDX - The starter kit for Arduino.
• Adafruit ARDX Experimentation Kit for Arduino - This kit is also very similar to the ones above with its own guide. You can find it here - Adafruit ARDX Experimentation Kit for Arduino.
• Arduino Starter Kit - The guys at Arduino.cc have their own official kit that is available too. The starter kit is similar to the ones above but has some interesting sample projects like a "Love-O-Meter". You can find it here and often at other resellers too - Arduino Starter Kit.

With all of the above kits, keep in mind that none of them are targeted towards NodeBot development. So the examples in booklets and such are written in the simplified C++ code that Arduino uses. For examples using Node, see the resources below.

There are a few key spots where you can learn how to put together various NodeBot projects on the web. Here are a few recommendations:

• Controlling an Arduino with Node.js and Johnny-Five - This is a free SitePoint screencast I recorded a little while ago that introduces the basics of connecting up an Arduino to Node.js and using the framework to turn an LED light on and off.
• Arduino Experimenter's Guide for NodeJS - An adaptation by Anna Gerber and other members of the NodeBots community from the SparkFun version of .:oomlout:.'s ARDX Guide. It shows how to do many of the examples from the kits mentioned above in Node instead of the simplified C++ code from Arduino.
• The official Johnny-Five website - Recently, the Johnny-Five framework had a whole new website released that has great documentation on how to use the framework on Arduino and other platforms too!
• Make: JavaScript Robotics Book - A new book released by Rick Waldron and others in the NodeBot community that provides a range of JS projects using various devices. Great for those who've got the absolute basics down and want to explore some new projects!
• NodeBots Official Site - Check this page out if you're looking for a local NodeBots meetup near you, or to read more about NodeBots in general.
• NodeBots - The Rise of JS Robotics - A great post by Chris Williams on how NodeBots came to be. It is a good read for those interested.

Andrew Fisher, a fellow Aussie NodeBot enthusiast, put together a rather simple project for people to build for their first NodeBot experience. It is called a "SimpleBot" and lives up to its name. It is a NodeBot that you can typically build in a single day. If you're keen on getting an actual robot up and running, rather than just a basic set of sensors and lights going on and off, this is a great project choice to start with. It comes available to Aussie attendees of NodeBots Day in one of the ticket types for this very reason! It is a bot with wheels and an ultrasonic sensor to detect if it's about to run into things. Here's what my own finished version looks like that I've prepared as a sample for NodeBots Day this year:

A list of SimpleBot materials needed and some sample Node.js code is available at the SimpleBot GitHub repo. Andrew also has a YouTube video showing how to put the SimpleBot together.

Andrew also collaborated with the team at Freetronics to put together a SimpleBot Arduino shield that might also be useful to people who'd like to give it a go as a learning project without needing to solder anything: SimpleBot Shield Kit.

That concludes a simple introduction into the world of NodeBots! If you're interested in getting involved, you've got all the info you should need to begin your NodeBot experience. I'll be organising the International NodeBots Day event in Sydney, so if you're a Sydneysider, grab a ticket and come along - International NodeBots Day Sydney, July 25.

If you build yourself a pretty neat NodeBot with any of the above resources, leave a note in the comments or get in touch with me on Twitter (@thatpatrickguy), I'd love to check out your JavaScript powered robot!

Continue reading %An Introduction to NodeBots%

Finagle’s Law of Dynamic Negatives:
Anything that can go wrong, will - at the worst possible moment.

Defensive programming, simply put, is programming with the intent to anticipate likely failure points. The goal is to circumvent those likely problems before they occur. You see the problem, right? There’s something inherently difficult with the advice “expect the unexpected” and it’s made many times worse when one alters it to “expect the unexpected and try to prevent it”.

Let’s look at some practical examples.

Continue reading %Defensive Programming in PHP%

When it comes to web design, most of the actual design is still done with tools like PhotoShop and Illustrator, and only later translated to code.

We seem to be stuck in a time warp - still using graphic design tools for web design.

Designing for the web is a whole different ball game. The nuances are different from general graphic design. Designing a layout that’s responsive, designing for conversion, designing for user experience are all part of the game.

And yet we're stuck using tools from the last century (well, almost) for modern web design. Isn't it high time we moved on to more modern tools, that were actually meant for web design?

In the past, Wix, Weebly and a host of other website builders hit the scene, but left much to be desired in terms of design freedom (and many other aspects!). Collectively, they left such a bad taste that many web designers shun any kind of website ‘builder’ tool even today.

But perhaps it’s time to revisit that.

In the last few years, there’s been a bunch of new ‘website creation’ tools that have cropped up. Tools like FROONT, Webflow, Macaw and Webydo that have been created specifically for web design. Leigh Howells calls them 'CoDesign tools' - tools that let you design for the web AND create the website (aka code) for you as you design.

That’s a radical thought for some. We're so ingrained into a our own ways of working, that it's difficult to comprehend an alternative method - with tools that let you create live websites instead of just mock ups and generate the code for you as you go along.

While I'm thrilled at the prospect of shortened development cycles and faster turnarounds, let's really evaluate the pros and cons to using these CoDesign tools.

(In a separate article, I'll compare some of these tools, so that you can better decide for yourself whether they're worth a try. In the meanwhile, you can grab a good summary over at SmashingMagazine and DavidWalsh )

1. You're working with the real web-flow. Not just creating pictures of websites. Though many these tools imitate PhotoShop's user interface, here you're not just making static designs. You have to actually create the elements, the divs and style them with real CSS - albeit using a PhotoShop like interface instead of writing code. You're designing in terms of real HTML elements.

This forces to think about how the layout will flow, how the containers will be placed and the overall complexity of your design. No more coming up with complex, contorted designs that just don't translate to code. All without actually writing a line of code. This is great for designers keen to learn more about their craft and eager to do real web design.

2. No more showing off mock ups. You can demo live websites! You no longer have to keep sending a bunch of psd files to clients and then try explaining to them how things will look just a little different on the real website.

In fact, you don't have to send a bunch of psd files back and forth to the developer either. And no more begging and pleading for quick code changes just before the demo.

These new age tools generate the code for you, as you go along. Meaning, you have a real live website from day one that you can demo to clients, that you can tweak as you want, when you want. And the changes are visible almost immediately.

3. Faster, more productive Design & Development cycles. Though this follows directly from #1 and #2, it needs to be stated explicitly. Can you imagine the amount of time saved without the multiple iterations back and forth between designers and developers?

While these tools do generate the code for you, it may not be fully compliant (Webflow is the only tool that generates compliant code) and will require some amount of editing - meaning you do still need to work with a developer, but the coding cycles will be shorter and faster, as will the number of iterations between designer and developer.

4. Your design holds truer to your vision. Remember the time when your developer told you the amazing feature you included couldn't be coded? Or when the live website turned out to be so way off your design and left you wondering what went wrong in the translation from psd to code? Well, all that's now history. With these codesign tools, you're actually creating the live website, code and all. You see the real website upfront - it's tangible from day one. You have full control over your design, and your website.

5. Responsive is just waaay easier. I left the best for last. No more making multiple mockups for different device sizes. No more fumbling about as you try to explain the layout transitions across different device and viewport sizes to the developer. And no more struggling with media queries. Each of these tools make it easy to build in the layout transitions at just the right breakpoints, all with a few clicks. Didn't I say this was the best part!

6. No coding required. Didn't I mention these tools generate the code for you?

But it's not all a cake walk. These tools are still developing and have some way to go before they take over PhotoShop and WordPress. If you have any of the following needs, or limitations, you may be better off sticking with your current tools and workflow.

Continue reading %CoDesign Tools: Is it Time to Switch?%

The very improbable has happened: Podcasting has become sexy. According to Pew Research Center, the increased reach and upward trend line of podcast consumption is evident in every available measure – the percentage of Americans who are listening to podcasts, the level of public awareness and how many podcasts are being hosted and downloaded. Most […]

Continue reading %The Definitive Guide to Podcasts%

Ruby on Rails is an amazing framework for building web applications. The Ruby and Rails ecosystems are very active and mature, with many libraries for solving the various problems encountered by developers. But one particular area where I feel Ruby lacks options is reporting. Many solutions exist in Rails for generating reports, most of them rely on generating HTML and converting to PDF. This approach has its advantages, but falls apart for complex and pixel perfect reports.

Enter JasperReports. JasperReports is a very popular open source reporting library widely used in Java world. Many of you may be curious about how to use a Java library in Rails. There are many approaches, but the one I prefer is to JRuby. This requires you to convert your application to JRuby, which is quite simple to do these days.

Continue reading %Create Great Reports with JasperReports%

If you need to write modular and reusable comments, Connect could be the best solution for you. It deals with an extensible HTTP server framework for Node.js using “plugins” known as middleware.

A middleware component is a plugin that gets a request and then does some processing, after which it might handle and end the requests or pass them on the next middleware plugin. The plugins that process the request and pass it on the next handlers are called filters, while the ones that actually handle the request are known as providers. In the first group we can find request logging plugin or authentication plugin, just to mention a few examples. As for the providers, they would mainly be part of the business logic of your application.

In this article you’ll see how to get started and use the Connect middleware framework in your Node.js applications.

Continue reading %Getting started with Connect%