I’m going to divert from my normal discussions of programming to talk about something I think is very important and still somewhat related to programming.
It’s time to break out the Champagne and celebrate because today the WC3 has released the fifth major version of the HTML specification and with this specification comes the recommendation from the WC3 to start using HTML5.
While HTML5 has been a specification for years it wasn’t until today that the WC3 has officially told developers to start using it.
By this point most developers and browsers are already supporting HTML5 with minor exceptions when it comes to video and audio support.
I’m honestly very happy that HTML5 is official. Now I just need to wait a bit longer until ECMAScript 6 gets released and all my front end problems will be solved.
I’ve recently been working on a lot of Node.js projects, for myself, with my students, and for national organizations. Because I’m a University instructor I’ve been getting a lot of questions about what the best practices for Node.js are from every project I’m involved with. I’ve worked with Node.js for years and know all the best practices myself, but I had never seen a list that explained the best practices to my satisfaction. So, I have put one together taking all the best practices agreed on by the community and explaining why each practice is the best way to write Node.js code.
If you want to improve these best practices in any way please don’t hesitate to create a pull request to the GitHub repo.
Here we go.
You may not see it from my GitHub account but I commit and push code to various projects a lot. When you are using Git in a collaborative manner like this several problems can crop up. Let me explain how I minimize or even eliminate these problems and explain my general outlook on collaborative programming.
Recently, I have been working a lot with WebSockets, specifically with Socket.IO. As a former ActionScript developer I love being able to return to using events to send and receive data as well as having my application get real time updates from the server. It feels so natural and fits really well into the types of applications I like to build. However, I wanted some more organization. I wanted a library that was designed around CRUD and WebSockets. Something like Mongoose, but on the frontend. I looked all around GitHub and found some libraries that were close, but nothing that was perfect, so I decided to make one myself.
Cordova is a great platform for building native feeling mobile applications on Android and iOS with web technology like HTML, CSS,
Obviously you have to use or write a CSS library which include all the UI components from the Android system and styles the appropriately.
Luckily developers have already created these types of frameworks and today I’m going to explore two of them for making web and Cordova applications look like native Android applications.
I’m fairly vocal about my opinion of Microsoft products. They have never made a single that is better than the competition, except maybe C#, but only maybe.
IE vs Safari vs Opera vs Chrome vs Firefox: Chrome or Firefox win
Office vs iWork vs LibreOffice = iWork wins
Windows vs OS X vs Linux = Linux wins with OS X a close second
However, they have finally made a product that is I would use over the competition, and most developers I talk to agree.
I had always been curious about DuckDuckGo and played around with it a few times in the past, but in May of this year DuckDuckGo released a new interface and a ton of new features. On July 9th I decided to give it a try and use DuckDuckGo as my primary search engine.
Here are my thoughts after using DuckDuckGo as my primary search engine for a month, both good and bad.
I’ve been opposed to using data-binding for a long time, until recently when I found a data-binding library that makes data-binding optional, easy to write, and framework agnostic.