Monday, August 4, 2014

A Quick Look at Modern Text Editors for Web Development

Even though there have been text editors for a very long time it seems there is still room for innovation. You might think that perhaps Vim, Emacs, is enough. Regardless new alternatives seem to be popping up. In this post I'll take a brief glance at a few to give you some idea of what's going on in the field.

Editors

Some OS X users might still remember TextMate (now open source). You could say Sublime Text pretty much replaced it. I tend to use both Vim and SublimeText with Vim bindings these days. There are a few interesting alternatives around the corner, though. Particularly Light Table, Adobe Brackets and GitHub Atom have gained publicity and I'll take a better look at those.

Light Table

Light Table is perhaps one of the most hyped new editors out there. It provides an interactive programming environment. You can execute your code within the editor, modify and inspect it as it runs. You can see the concept in action in the video below.

Besides being suitable for interactive work it is possible to extend and customize Light Table somewhat as seems to be true for the newest generation of editors.




Adobe Brackets

Inline editing in Brackets
Brackets is an editor specifically designed for web development. Rather than just being a fancy text editor it provides an integrated approach for web developers.

For instance instead of having to modify HTML and CSS files separately it allows you to open CSS related to given HTML tag within the view itself.

It also provides live editing as a built-in feature. This way the changes you make are visible in the browser instantly without having to refresh it explicitly. Currently this works with Chrome only.

There are also advanced debugging capabilities that are not available in regular editors.

The video below illustrates the basic ideas well.



GitHub Atom

Just like Brackets, GitHub's Atom is built on web technologies itself. It comes with a package manager built-in and is easy to extend. You could say it has been very inspired by Sublime Text and it is likely easy to adopt if you use ST already. In addition there's Node.js integration available. That's another handy feature for plugin authors.

It's probably not an earth shattering editor yet but given its modularity and backing it would not surprise me if it became very popular within a year or two as it develops.

Again, check out a video to understand some of the basic ideas behind the editor.



Other Editors

Besides the editors discussed above there are entire IDEs to check out. WebStorm is definitely worth checking out if you are into that sort of thing. Angular support in particular might be of interest for some.

Dart programming language comes with an environment of its own. Dart editor benefits from optional typing supported by the language and makes it easier to catch certain category of errors earlier than in vanilla JavaScript without a runtime hit.

Besides "traditional" editors there's a whole category of a web based ones. Cloud9 and Codebox provide good examples of these. These type of tools allow collaboration (ie. pair coding and such) in a way that might be difficult or impossible to achieve using some other editors.

Lighter web based editors such as JSbin, jsFiddle or jsdo.it have their place as well. They might not have as strong collaboration features (ie. realtime) but are often enough for illustrating a specific problem or implementing small demos.

Conclusion

Overall it seems editors are specializing and provide more support for interactive editing than before. Older editors will still retain a following. Newer alternatives might be easier to modify and some even provide special functionality that has been developed particularly web developers in mind.

For now I'll stick with my Vim/Sublime combo and keep an eye on the newcomers. Transition from Sublime to Atom should be straightforward for instance. As long as there's support GitGutter (git diff in gutter), EditorConfig (enforces coding style), formatting and interactive linting I should be a happy camper.

Live editing, as provided by Brackets, can be provided externally. These days I prefer to use BrowserSync and invoke it through a Gulp based build. Broccoli might be a good alternative longer term but I'm waiting for it to mature for now.

The next step, bi-directional editing, is mostly handled with Tincr. Of course editing pre-processed files (SASS, LESS, ...) remains a problem but you can't get it all, at least yet.

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.