Thursday, July 3, 2014

How I Learned to Stop Worrying and Love React

You could say JavaScript frontend development advances at a rapid pace. Every few months new technologies are introduced. One of the perhaps most interesting recent ones is React.js. It is a library developed by Facebook that focuses on rendering views.

Most importantly it bridges the gap between frontend and backend. It is possible to render the markup on backend and have frontend pick it up seamlessly. It is blazing fast thanks to its DOM diffing algorithm. It is so performant that even Atom, an editor developed by GitHub, is moving to use it.

I see solutions such as React as a natural next step. Backbone, Angular, Ember and such will still have their place. You can even mix React with existing technology to enjoy some of the benefits.

Web Components can be seen as a competing approach. polymer.js, a project established by Google developers, would be the library check if you want to learn more. Maybe Web Components are the way of the future.

Getting Started with React

Time to react by
Ian Nolan(CC BY-SA)
There is not that much to learn in React. It is more about understanding some basic concepts. When coding in React you'll split up your view into smaller components that may contain others. They can contain some internal state and properties which may be passed to the component to render. You can also deal with events at these components and then manipulate the state.

The fastest way to understand the way it works is to check out the official Fiddle and then try out some tricks available in the documentation. The Fiddle I linked to relies on something known as JSX. It is an XML like syntax designed to make it easier to write templates. There are tools available that can render it to regular JS. You can also write the JS directly although it's more cumbersome.

The biggest gotcha with using JSX is that it gets more difficult to use tools like jshint since they won't recognize the custom syntax. EDIT: It is possible to use a wrapper such as jsxhint to lint JSX code. (Thanks Esa-Matti.)

Invoicing Demo - Combining React with JSON Schema

I wrote a small invoicing application as my first React exercise. Try filling some fields. You can get an invoice simply by printing out a pdf.

Technically it is somewhat simple. Initially I wanted to use Angular and some form library that supports JSON Schema well. The idea was to generate a form based on schema and then use that to control model that is tied with the preview you can see at the demo. Unfortunately I was unable to find a library that supported nested properties (ie. objects inside array).

As I didn't feel like hacking some existing library and React has been on my list of technologies to learn and adopt for a while, I started looking into a JSON Schema based library. I managed to find one in form of plexus-form. After fiddling with their demo for a while I realized I should go with it. Even though it wasn't aesthetically most pleasing the core worked very well. After some iteration with the author the library we made it fit my purposes perfectly.

Besides React and plexus-form I adopted Gulp in this project. It is a streaming build tool that avoids some of the complexity of Grunt. Apparently it is faster and best of all given all the configuration is in code it's easy to maintain and develop using it.

The final bit of new tooling I adopted was Tincr. It is a Chrome plugin that allows bidirectional editing of CSS. I like to fiddle with CSS in Chrome Inspector and then move the changes to actual CSS. This plugin allows me to skip that latter part and makes it much faster to do tweaks.

If you study invoicing app source, you'll notice I've split it up within components and a form schema. The components are fairly self-contained. I could for instance reuse Form pretty much as is in some other project. I also love the fact that if I want to add a new field and hook it up with the preview, I need to modify just the schema and preview template.

You can also see that I used something know as LocalStorageMixin in my form. Adding that little line of code there allowed me to persist the component data within localStorage so it's available when you reload the page. How neat is that?

The build is based on browserify and various other tools (BrowserSync, reactify etc.). Browserify allows you to use the same module scheme you have gotten used with Node.js. This workflow also enables server side rendering with minimal effort as an example by mhart illustrates!

Weather Demo - Combining React with FRP

Even though React works great as is dealing with events could get hairy. Functional Reactive Programming (FRP) provides a solution for this problem. It allows you to control events on the level of streams. You can modify these streams for your purposes and then pipe them to your components. As it happens React and bacon.js, a FRP library, fit very well together.

To make things easier there is a BaconMixin that provides the sort of functionality that makes this type of work simple. I still don't understand every details of it but to get started I forked the original GitHub based example of the library. I modified it to fetch weather information from OpenWeatherMap API. It is not very aesthetic in its current form but it was more about piping.

As FRP is still quite a new topic and not that well understood I recommend checking out André Staltz's excellent introduction. It is one of those abstractions that might change frontend development as we know it.

Conclusion

You could say I have been quite impressed by React so far. It simplifies development a lot. Having stellar performance doesn't hurt. Compared to something like Angular there is far less to learn. Of course it's a different beast. Apples and oranges.

To scale up from just doing cool little things with views, you could look into rrouter, a routing library, and Fluxxor. Latter provides tools that allow you to implement something known as Flux architecture.

If you need to implement small interactive views I would say React can be a very good fit. There are some gotchas of course (ie. dealing with Bootstrap plugins) but overall the experience has been very positive.

Monday, June 30, 2014

Linkdump 22 - Business, Software Development, Programming...

Time for a Summer dump! See also previous one.

Business


Software Development


Programming


Web Development


Hardware


UX


Art

Wednesday, June 11, 2014

Projects Are the Antithesis of Projection

It is a well known fact that software projects fail more often than not in some way (ie. Chaos Report). Either deadlines are missed, objectives are not reached, budget goes beyond allotted, you name it. If you are a software developer, you have likely blown up a project at least in one of these ways.

Essentially a project is a control mechanism. By definition it is something performed by a temporary organization that should reach the project goal. Once the goal is reached, the project is done and closure is reached. The organization may disband and move onto other projects.

What if there was some other way? Who says software has to be developed within projects always?

Projects Are the Antithesis of Projection

Compass by The B's (CC BY-NC)
Projects might work for one-off thing that you can implement and forget. This is missing one key point, however, software evolution. A project might reach its goals on time and on budget but what about the future? The way I see it projects are an antithesis to this kind of projection. They encourage to focus on short term while forget about long term.

That said maintainability concerns can be taken in count during project. It is just that by definition they don't encourage to take the long term view. As projects are performed by temporary organizations there might not be commitment to reach for the best long term result either. And what is the best long term result even? What looks good for the project/product owner might not look good for contractor.

The tried and true engineer's triangle applies here. You always have to make a compromise between good, fast and cheap. It simply isn't possible to get everything at once.

Alternative Control Structures?

Control structures by Martin Fisch
(CC BY-SA)
Given projects are about control can we organize development using some other structure? Projects by definition lead to side taking. There must be some product owner and the people that actually implement the project (ie. contractor). The goals of these two parties are often different and can lead to conflict.

Let's say we build a project based on a fixed set of requirements, fix the cost and schedule. After that it's up to the contractor to implement the project within those constraints. The problem is what if the requirements change during the project? If the cost and schedule are fixed and the product owner is not willing to compromise, this could lead to serious issues. Something has to give in.

What if instead of pushing and fixing we did something different? The product owner likely has a good idea of the product goals. An alternative control structure could be developed based on those. Rather than fixing everything upfront and then trying to find the cheapest company to do the work, something else could be tried. How can you achieve this without taking sides so clearly?

What if you tie the destiny of the product owner to the destiny of the contractor somehow? Instead of aiming for something as cheap as possible to maximize short term gains you would think long term. One possible solution is to treat the contractor as a business partner. In product development this might mean something such as profit sharing.

You could also build something on weekly basis (ie. charge per week against results). Make the arrangement so that either party may fire the other after each week. If either party is disappointed for some reason and wants to move on, let it happen. This forces both parties to focus on building trust if they want to keep it going on.

There are still sides but at least they are aligned better than in traditional projects. There is a clear continuum and it is in the best interests of both parties to maximize their efforts to gain trust. That is essential for maintaining a long term relationship and minimizes some of the risks. Now that you can think forward even projection becomes possible and you can think about future.

Conclusion

I think it is very interesting to follow the current #NoProjects discussion. It feels like we might be onto something here. I am not saying projects could not work in some contexts. More often than not it feels like a construct that has been developed to maximize the wrong things. It's hard to project with projects.

This post was inspired by Allan Kelly's post on the topic. Also the comments on the blog were very insightful so I recommend checking that out if this sounds interesting!

Tuesday, May 20, 2014

Linkdump 21 - Business, Software Development, Programming...

Dump time! Also see the previous one if you haven't already.

Business


Software Development


Programming


Web Development


Tuesday, May 6, 2014

spyder - Indexer and Scraper Runner

Spider by Josch13 (CC0)
Scraping data is relatively straightforward. You simply dig in to some source, extract what you need and store it. I went through the basics of scraping using Node.js earlier. Even though the task itself is simple once you need to scrape a lot you will end up with plenty of boilerplate and there is plenty of repetition.

In order to deal with this issue in a recent project I ended up writing a little framework that makes it easier to write scrapers. spyder provides structure for both writing and running your scrapers. It relies on two basic concepts: indexing and scraping.

In the first pass it executes an indexer. The purpose of this is to extract links to scrape. In the second pass, scraping, it makes sure each link is scraped and then helps you to deal with the results. You can also control the delay between individual scrapes to avoid hitting the server too hard. I'm not sure if that actually helps measurably but I guess it doesn't hurt.

Even though I have used the tool scraping for web, this doesn't mean you cannot use it beyond it. I can imagine it could be useful for extracting insights out of a filesystem. You could set it up to run against a directory of images and analyze them for instance.

If you are into indexing and scraping, check it out. I'm open for improvement requests.

Thursday, April 24, 2014

Art - Developing Taste and Value of Copying

Eye study based on reference using "paint roller"
In addition to doing quite a bit of traditional work (mainly figures, NSFW obviously) I have started to explore digital medium. Even though I enjoy the feel of physical medium, going digital allows you to experiment and go fast. Most grievous mistakes can be fixed. This isn't possible in physical work always or it will take a significant amount of effort at least.

It is surprising how well skills gained in physical world translate digital world. Observation, values, colors, it's all more or less the same. It is much easier to reach certain colors when going digital, though. If you work with something like pastel, getting the color you are after can be difficult. This is something I am learning to do still. Same goes for watercolor. The range of yellows is very limited compared to something like blue for instance.

Copy of Bird Sirin

Developing Taste

As a part of "going digital" I have been trying to develop my taste. Sergey Kolesov has become one of my favorites. There is something special in his works. They read very well and have that grungy feel I like. I would like to assimilate a part of that into my personal style.

Often digital works of art look too smooth or finished. You can achieve this using physical mediums too but it's way harder. Some applications, such as ArtRage or Painter, go to great extents to mimic the physical world. It is possible to achieve similar results using textured brushes. For me good digital work is all about certain clarity mixed with grunge.


Copy of The Moth King
In order to understand a couple of things better and learn the tools (ArtRage 4, Corel Painter Lite) I have begun to make copies of Sergey's work. Generally I spend roughly 20-30 minutes per piece and try to work fast. Big strokes and observations first, refinement later. For now it's about getting the basics on some level before moving further.

Due to the time constraint I cannot get too attached to some detail and I can afford to make mistakes. Sometimes doing a piece a couple of times allows you to capture certain aspects better on subsequent tries. I also try to work using different tools to get an idea of what sort of output you get out of each.

I suppose I could try to simplify my approach even further. Maybe doing studies with just two or three tones with even less time could be a good next step. Just capturing the values right makes for a believable picture.

Conclusion

I think doing these small little studies has taken me to the right direction. I know I have tons to learn about both physical and digital mediums. In some strange way they seem to complement each other.

I would recommend doing this type of work. Pick some works of an artist you like and copy away. You might be surprised to notice how much you can learn just by doing that. It will also give new kind of appreciation for the original art. You will notice things you have missed earlier.