During winter 2015/16 I will deliver inhouse courses about development with JavaScript and AngularJS to teams at Puzzle ITC, mtrail GmbH, Mobiliar, Postfinance and SBB.
I will also deliver public courses for DigiComp and TechTalk:
At DigiComp my next course “Frontend-Entwicklung mit AngularJS” is scheduled for December 17th & 18th 2015 in Bern.
There are already enough registrations so that the course is guaranteed to take place, but there is still room for more participants …
Last Week was the Angular Connect conference in London.
Unfortunately Angular 2 is still alpha … the highly awaited beta version was not released at the conference.
Besides Angular 2, TypeScript and Reactive Extensions seem to be the technologies that you should start to look into for future develoment with Angular.
The sessions are available on YouTube, I am still catching up, but the qualtity of most sessions is very high.
The App and Play stores have turned out to be exceptionally poor places to run a software product business for most developers.
DHH (the creator of Ruby on Rails) argues against the myth of profitability of mobile app development today. Apps are a great distribution channels for services, but they are not the product you should try to make money with.
the fastest known Android device available today performs 5× slower than a new iPhone 6s, and a little worse than a 2012 era iPhone 5
The post is highly interesting. It seems that iOS users are much better off using modern web sites and the Android ecosystem is actually threatening to hold back the progress of web technologies …
I am currently working for a team that is about to build a web frontend for their in-house legacy system. The web frontend is basically a greenfield project, and the team can freely choose their technology stack.
I developed a small technology prototype in AngularJS and React. For both solutions I used npm and webpack as a build environement. In the AngularJS solution I used TypeScript and in the React solution I used ES2015 (formerly ES6) and Babel.
I presented both solutions to the team, and let them decide which stack they like to choose for the actual project.
The team decided that they felt more comfortable with the solution based on React.
There were two main reasons:
AngularJS is currently in a strange state, since Angular 2.0 is announced and hyped but not ready for production yet. If you start a project based on AngularJS now, you get the feeling that you are writing in a legacy technology right from the beginning.
The React solution left a conciser impression and was clearer to grasp by the team. For example to realize a “component” in AngularJS you have to understand Directives (a DDO is pretty arcane for a newbie) and the implementation is spread over several entities (DDO, controller, template …). In contrast to that the approach of React to components is much easier to grasp.
This decision was made some weeks ago. In the meantime I set up the real project with the following components:
Wow! Amazon and the Hackers are both continuously scanning public repositories for passwords!
This story should make you reconsider where you leave your credit card information… things might get out of hand, even if you think that you are just using a free service …
Gojko wrote an interesting article about the current trend of scaling Agile. Unconventional as always, he draws anaglogies with “The Lord of the Rings” and escaping a concentration camp in WWII.
He argues that our industry is obsessed with effort instead of focusing on outcome.
His main explanaition why Agile does not scale in most attempts is:
On a small scale, effort does boost outcome.[…] On a larger scale, effort no longer directly relates to results.
Interesting to see different perspectives. Although I have a hard time to take the second answer seriously. In my experience not many enterprises are looking for the mythical “10x engineer” and are willing to pay these extravagant figures …
If you missed SwissJS last July, the recorded sessions are now available on YouTube.
If you just want to watch one session, I recommend “Creating UIs for the WebA Audio API” by Stephen Band. His usage of the browser to create music is impressive and its a refreshing non-enterprisy topic.
Christin Gorman is adressing the problem of over-engineering in typical business applications. This one is more serious than previous presentations by her, but she kept her refreshing way to present …
Peter Paul Koch of QuirksMode argues that we are maneuvering the web into a dead end. Instead of trying to compete with native apps by cramming more and more features into browsers, we should focus on the web’s strengths: simplicity, URLs and reach.
We get ever more features that become ever more complex and need ever more polyfills and other tools to function — tools that are part of the problem, and not of the solution.
In sum, the story of overwork is literally a story of diminishing returns: keep overworking, and you’ll progressively work more stupidly on tasks that are increasingly meaningless.
The supported migration scenario from Angular 1 to Angular 2 will not be based on the Angular New Router (aka. Component Router) any more (it seems as the New Router has been killed as a standalone project anyways). The Angular team posted a sophisticated plan how migration will look like. It looks interesting, but as far as I gather it’s still only a plan, the bits are not available yet …
Online courses are sprouting out of the internet like mushrooms in autumn … I for myself have currently a subscription to Pluralshigt and to Egghead.io. But there is so much more …
The business seems to be lucrative, at least for some teachers …
The original enrollment system cost $200 million and would have required $70 million a year to maintain. The new version of the site cost $4 million to produce, with annual maintenance costs also $4 million.
There is a lot of debate whether the 10x developer is reality or not. But this article proves that the 10x team is definitely reality.
But the article also points out that it does not (only) depend on the people in the team, but also on the project setup: Is the team in a position to make a difference, or is it helplessly entangled in bureaucracy.
The biggest foe is generally risk aversion. People in government are trained to not do things differently because there’s often really bad consequences when you try something differently and it fails. We run up against this all the time
I also find the philosophy how the USDS attracts people and forms teams very interesting:
We don’t make career hires. We’re not building a career organization. […] We are relentless about trying to hang onto the ruthless mission focus here. We are built for short term appointments.
At small scale, Agile is great. At large scale, Agile is stupid.
Jurgen Appelo, the author of Management 3.0, gives his thought about the recent attempts to scale Agile and the fundamental flaw that at the base of all those methodologies that want to apply existing Agile practices at large:
Scaling Agile is indeed a problem, because the Manifesto doesn’t scale
in the first place. It was intended to describe small projects, not
large enterprises.
Agile: It used to be simple
SCRUMstudy turns my 16 page framework into 350+ page methodology. They didn't read Agile Manifesto.
JavaScript, it might have been botched but we loved it because it was simple: Write the code and press reload.
ECMAScript 2015, formerly known as ECMAScript 6 … to use it today, you have to understand transpilation and module loading and deal with all the accidental complexity around Node.js, npm, webpack, babel, traceur, jspm, SystemJS etc.
