When it time came to print a new batch of business cards. I tried to find the latest design we’ve used a few years back and update them.

Than, suddenly, I though: what if I had an app that allows sharing a business card. I searched App Store and found a few not trivial apps that probably only engineers can use.

I had strong vision of how the app should look like and what should it do.

1. It should allow having as many cards as I need. Well, I hold a few positions in a few companies Astrails work with.
2. It should not keep my personal information somewhere on remote servers, who knows how well the data is protected there.
3. And most important: it should be super easy to the receiving party to save the card, no extra apps should be required for that.

Imagine that you’re starting a meeting with 3 participants.

Asking their phone numbers/emails and sharing your contact from a phone is not an option. It will take a lot of time and introduce an unnecessary hustle. The sharing should be as simple as passing a printed card.

So, the answer for the last question is QR code with embedded vCard, default camera app since iOS 12 and Android 9 recognizes QR codes. And you should only show your phone to participants.

That’s how Virtual Business Card was built. There is a video there, so feel free to check it out.

Right now it only works on iOS, Android version is coming soon.

This is the 4rd and a last post of the series, Part 1, Part 2, Part 3.

The initial release of AngularJS happened just one week after the release of Backbone.JS, but was pretty much ignored for a while. It took some time to understand that in addition to Javascript, HTML and CSS, frontend developers that wanted to succeed with Angular had to learn ng-extensions too. Within a few years, Angular became very popular among developers. The only problem was that it was very easy to get started with it, but pretty complicated for more advanced things.

Exactly one year later, ex-Rails core engineer Yehuda Katz released Ember. The first version was super opinionated and had a high entry barrier. Instead of trying to solve some small tactical issues, Ember directly targeted full-featured client-side web applications.

Two years after that, Facebook released the first version of React - a breath of fresh air for frontend development. No monolithic applications, no misplaced MV (whatever) patterns, no extensions. Yes to Daft Punk’s Random Access Memories, album released that same year. The concept of React was very simple: representation is a function of an application state. Just implement the render function as a function of a state, include optional lifecycle callbacks, and React will take care of the rest.

Later, Facebook introduced Flux, frontend application architecture with unidirectional data flow. Dan Abramov’s react-redux based on Redux is probably the best implementation of the same concept of unidirectional data flow. It took about a year and a half for the community to catch up and by the end of 2014, React became extremely popular.

And at the beginning of 2015, Facebook released React Native, a framework for building native apps with React that introduced the concept of “learn once write many”. iOS and Android applications will not share 100% of the code, but it is possible to reach 60-90% depending on the requirements. Compared with 0% code sharing when developing ObjectiveC/Swift for iOS and Java for Android, this is quite an achievement. Especially when taking into account that development is mostly done using React and Javascript.

Angular 2 entered the beta stage in late 2015 and was released in September 2016. Its breaking changes and a few concept shifts deprecated most of the knowledge and experience that developers had accumulated while working with Angular. Some developers were angry about these changes because they had to re-invest time to basically writing everything again from scratch using Angular 2. But some were happy because the new version was better engineered and more fun to work with.

Initially released in 2014, Vue gained popularity around the same time that Angular 2 was released. It was what Angular JS should have been from the beginning.

At the end of 2015 and most of 2016 there was a popular joke: two new Javascript frameworks were probably released while you were reading this sentence. And another three have just died.

Q&A

So, what should I use now?

React. Unless you have someone on board who is familiar with Angular, then use Angular or Vue and consider React anyway.

What should I learn if I am just entering this field?

React. It will allow you to develop desktop/mobile web apps, native mobile apps, and even Windows applications using react-native-windows.

What’s next?

Progressive Web Apps are the next stage in web frontends. It deserves its own series of posts.

This is the 3rd post of the series, Part 1, Part 2, Part 4.

Ok, so now initially loaded web pages have almost no HTML code, but have tons of Javascript and CSS instead. This is good, because these assets could be served from CDN which in theory makes the whole page load much faster.

But the page load time is not the optimization objective. What really matters is the time that it takes for the page to become usable, in other words - when users can start consuming the content on the page.

So besides the time that it takes to load all of the assets, we also have to consider the time spent inside the Javascript to fetch relevant data using APIs and to render it on the client side by updating the DOM. It’s user CPU time that renders the content in this case. User CPU seems free from an application vendor perspective since the user pays for it and for the electricity to power it. But that’s not 100% true.

The first iPhone was launched about 2 years after the original AJAX piece was published. And that triggered a new epoch of mobile browsers. But mobile browser CPU time is not free. It doesn’t cost money directly. The price is the user’s disappointment with battery life. Now users don’t blame lazy developers who wrote suboptimal code, they blame mobile device vendors for using bad batteries.

Anyway, Prototype JS was released in the same month as the AJAX article and attracted a lot of attention. It allowed direct DOM manipulation, contained cross-browser abstractions, and was bundled with its own Javascript effects library. Prototype JS was probably the most important advancement in frontend development since the invention of CSS in 1996. In any case, the first version of jQuery was released 18 months later. It becomes a de-facto standard for the next 9 years because it was direct DOM manipulation done right.

A crazy mix of server-rendered HTML pages and lots of jQuery based mostly on spaghetti code to update these pages, plus a few JSON/XML APIs here and there, was characteristic of Web 2.0 development for many years. By that time, the prestige of frontend development had significantly declined. Backend engineers looked down on HTML/CSS/JS folks that spent most of their time showing and hiding divs and changing the colors of different elements.

Barack Obama inaugurated as the 44th President of the United States of America just 4 months before the first release of Node.js. Node.js was accepted quite sceptically as a nice try to bring Javascript to server side, and there was no significant adoption of Node.js in web development. Probably a release of Express a year later became a trigger of a wide adoption of Node.js. Today Node.js is a quite popular choice for backend development, especially taking into account that modern frontend frameworks allow the same Javascript code to perform rendering on both sides: server and client.

The state of frontend development was now where backend development had been in the late 1990s - a zoo of approaches and technologies. Different groups tried to come up with a frontend framework that would straighten out the mess. Jeremy Ashkenas came up with the most successful one at the time, Backbone.JS. Released in 2010, this client-side MVC framework restored some order to jQuery-based frontend apps. A few years later, Marionette came along to attempt to enhance the functionality of BackboneJS and to become a Rails-style opinionated frontend framework.

Then more and more engineers began to develop frontend-based apps. And the fun was about to begin.

This is the 2nd post of the series, Part 1, Part 3, Part 4.

So the main question is - what does the backend code do in order to render its output? Static assets aside, the response will most probably include data that was fetched from some sort of database. If the output is a full HTML page, it should also include proper HTML markup around the data. This is called server-side rendering because the content of the whole HTML page is rendered by the server.

The bigger the HTML page the more expensive rendering will be.

In earlier web applications, each request type was handled by a separate script file. The script was interpreted line by line to render a web page. Several approaches were introduced to make the code more maintainable and MVC was one of the most successful ones. It’s worth mentioning that Rails, a Ruby-based MVC implementation that was initially released the same year that Zuckerberg launched Facebook, contributed significantly to the wide adoption of the MVC design pattern in web development. Model-View-Controller frameworks for many languages were released in the late 2000s.

MVC separates the concerns of the backend code. Requests are handled by a controller, it uses models to fetch data. The data is passed to views which are responsible for rendering pages. It’s a much better solution than a single script file that does all of the above. But tons of CPU and memory are still used to prepare HTML pages that became bigger and bigger.

And then along came Asynchronous JavaScript + XML, aka AJAX, almost nine years after the FastCGI specification was published and in the same year that the 3rd episode of Star Wars was released. The AJAX approach suggests fetching extra data from the server to update the current screen without reloading the entire page.

Web servers can render many types of content in response to an XMLHttpRequest - including HTML segments that can replace an existing part of the web page, Javascript code that can do anything (including UI effects and replacing parts of the HTML page) once it is evaluated by the browser, and pure data that is serialized in XML/JSON format.

Javascript code running in a browser uses XML/JSON data to update the content of a page. Beforehand, Javascript was used mostly for UI effects. This marked the beginning of a significant shift in the concept of web development. It was the beginning of client-side rendering. This shift actually affects backends as well, that no longer have to render expensive HTML pages. Instead, their main function is serving APIs. It almost makes the V-portion of the MVC framework redundant, because JSON format doesn’t include anything but the data itself. Now server CPUs and memory can be used for better purposes.

Two months after the end of WWII in Europe, Vannevar Bush published an essay called As We May Think. He introduced a concept called memex, which became the forerunner and inspiration for hypertext.

Forty-six years later, Tim Berners-Lee released the very first web server, called CERN httpd, and a browser that worked on NeXT. Later that same year, Nicola Pellow developed a text mode browser for other platforms. At the same time, on the other side of the planet, Pablo Escobar surrendered himself to the police. CERN httpd’s latest version 3.0 is available on GitHub.

Two years later, NCSA published a specification for calling command line executables. The output of these executables could be rendered back via the web server over an HTTP protocol as a response. This was basically the birth of the dynamic web and ultimately resulted in a formal CGI standard.

Three years of extensive use of this solution showed that launching a separate process for each request and tearing it down at the end of the request was a waste of resources. Let’s ignore the forgotten Netscape server API for a minute and note that Fast CGI was the greatest achievement since CERN httpd. Requests from the web server could be routed to a FastCGI server (via a socket, TCP or named pipe). The FastCGI server keeps data-rendering processes running for a series of requests, so that responses are returned to the web server and then to the client. This approach significantly reduced server load and response time.

Another popular approach that was actively developed during that time is called embedded interpreters. Some well-known examples are Apache’s mod_perl (released in 1996) and mod_php. They basically keep the interpreter running constantly in order to save launch/tear down overhead and to transfer the script code to the interpreter process, which in return renders back the response body. Interpreters usually have access to the web server’s internal APIs and act as extensions of the web server.

CGI, FastCGI and embedded interpreters are still widely used today (Apr 2018).

But all this has nothing to do with frontends. I just mentioned it to give you an overview of how backends render their outputs to a browser. Of course I skipped some basic things like sessions, caching, reverse proxies, database connections because they are less relevant to the big picture.

The big picture is quite simple. A request is received by a web server, which somehow gets the output of the backend application code and renders it back to a client application. In most cases that client application is a browser. As for static HTML / CSS / Javascript assets, the backend application code just reads content from a file (database, Redis, Memcache, tape, punch card or whatever storage is used) and sends the content back.

This is the 1st post of the series, Part 2, Part 3, Part 4.

Content Creation Flow (5 mins reading time).

Today we’re going to talk about an effective way of defining new product features.

A product feature can be defined in two ways – from either a marketing or engineering perspective. The marketing approach means explaining how the feature benefits the customer, and the engineering perspective means explaining how that feature works.

Some product managers may miss this distinction and explain a new feature to their engineering team from a marketing perspective. As a result, engineering may work really hard and possibly proceed in the wrong direction, losing time and money for the company.

I’m going to start a series of short digest blog posts that will cover a few things worth mentioning. I sumble upon a lot of things reading different sources, here I will share the most interesting ones. Well, at least most intersting for me.

Lean Startup Machine is coming to Tel Aviv this summer. Signup for a chance to win a free ticket.

Lean Startup is the hot new “thing”. Its a practice that lets entrepreneurs build successfull startups in the most efficient way.

I had a lot of things to do last Thursday, Feb-17. I met a friend from abroad 3am at Ben Gurion Airport and spent several hours talking before we went to sleep, signed a contract for developing killer web app at 1:30am, and finally gave a presentation at The Junction at 4:30pm.

We presented on IGTCloud Ruby On Rails Day today.

Agenda was a bit different this time, not only technical presentations but also a few words about modern approach of building web applications.

Find the slides below.

http://markupslicer.com

Supports ERB and HAML for now, vote on site for more formats.

Beautifully crafted, totally free and it’s kinda fun.

2008 was the year when we finally switched to full time consulting. And like all consulters we faced the problem of correct pricing. There are two well-known ways to charge a customer: per-hour rate and fixed bid quote, and several combinations of them.

We just incorporated our own Ltd. company.

It was coming for a while now but we finally got to it when we started to hire people :)