Thu, Jun 12, 2014
At sope.io we built a product discovery app, Zudu.
I want to sum up some things I learned along the way here:
Choose the Right Framework
The first version of Zudu was built using Backbone Marionette. We decided to rewrite it because Marionette turned out as unnecessary abstraction and we often had to work around it.
Writing the Angular version was straight forward and we ended up with less than half of lines of code. Also the minifed version is a little smaller.
Sure, it’s easier to write good code if you do it the second time, but the Angular Way seems to be a better fit for this kind of application.
Backbone is still a good tool for other usecases.
Both have their strengths.
Design Your API Carefully
Building a proper REST API makes the required client-side code for syncing the data quiet simple and HTTP status codes map nicely to appropriate messages for the user.
A good API Design can make a big difference.
Build Pluggable Components
If you happen to build your own node.js framework around express.js make use of the pluggable nature of express. You can build independent components and just plug them in at whatever url you want.
Skip Unnecessary Abstractions
MongoDB is a powerful and flexible database and it served use well. However, looking back I would skip the mongoose abstraction. The main thing mongoose gives you is validation via schemas. This makes it more familiar if you mainly worked with relational databases before. But it’s not really needed for MongoDB. Having schemas you tend to think relational again.
You are better off just using the native driver for MongoDB and keep the hands from abstractions you don’t need.
Write Many Small Functions
For most server components the API is the entrypoint. The method handlers get easily big and bloaded with asynchronous code. Make sure to separate different concerns in their own functions to avoid too many nested callbacks.
Also separate buisness logic from the API completely where possible.
These might look like basic software design principles, but working with new technologies we end up running in the same pitfalls over and over again.
It’s not an easy task to find the right way to use general principles in an idomatic way for a certain software stack.
Tue, May 20, 2014
SVG is an underrated tool. It seems people are more exited about Canvas because it’s simple.
But SVG lets you do a lot of things with way less effort.
It’s just scary because it’s so powerful.
Normally when I should do something in SVG I automatically start thinking about which library to use this time.
But for most simple stuff (like charts) you don’t even need a library.
All the styling can be done in CSS. And you can dynamically manipulate it with jQuery.
Sounds familiar? - SVG just works like the DOM you’re used to work with!
Look at this nice, animated graph below. Doesn’t it look like normal jQuery code?
You can just start using SVG with your existing tools.
Don’t be afraid of SVG. Canvas is not always the easier option for grafics.
Choose the right tool for the job.
Sat, May 3, 2014
Writing short automation scripts is a common task.
But figuring out the right shell script syntax can be a daunting task.
Fortunately Ruby has really well designed System APIs
and comes with all the tools you need.
Even better is that the focus on usability also
extends to third-party modules and you have a big community
providing you everything you need.
Another nice thing about Ruby is that you don’t need to look up
APIs that ofen because they work exactly the way you would expect them to.
Here is a short script to take some screenshots of a video collection:
Fri, Apr 4, 2014
The only really reason you create something with
<canvas> is performance (think games).
For almost all other 2D graphics you better use SVG.
If you want speed WebGL ist even better.
Luckily PIXI.js uses WebGL with Canvas fallback so you don’t have to worry about bad browser support and difficult APIs.
And it works pretty well.
Checkout out this demo. It re-calculates and re-draws this whole graphic every frame and still appears smooth.
And as you can see the API is pretty straight forward.
Fri, Jan 10, 2014
Normally we don’t need to implement our own filters.
Photoshop does a way better job than we could.
But someone has to build Photoshop and the camera app on your phone, right?
As a web developer it might also be interesting to know how filtering actually works.
It’s always good to understand the tools you work with
and filters are part of the web now with the latest SVG and CSS updates.
You can test the different filters and look at the code.
It might surprise you how little code is neccessary.
Feel free to play around and create some nice filters!