Your Lead Architect Doesn’t Really Understand Microservices

http://thenewstack.io/genius-techie-doesnt-really-understand-cloud

There is no doubt that hype trumps learning, and that’s just a fact; we have a wealth of available and immediate information now in the Internet age. It takes time for experts to discern what matters and what does not. But in the end, following the leader may be the best approach of all.

I’ve seen this exact same story so many times in the wild. Many companies (mostly enterprises) still don’t get their mind shifted from the old “this-is-my-application” (monolithic) to a new service oriented “cloud” architecture.

Developers still tend to think about it like the SOA approach they learned in a training (or at university) many years ago… but just inside their own world. So at the end, they often come up with a largely decoupled monolith, that still heavily depends on that one database or a “special” system configuration to make that application work.

 

Making of COPE

Yesterday i found this one in my archives. It is a clip made out of many images, that have been taken during the development of COPE at Bechtle back in 2014/2015.

 

If you like it and want to create something like this on your own. Here is a short step by step guide on how to do it on Mac OS X.

Step 1: Install imagesnap

brew install imagesnap

Step 2: Create post-commit hook

Add the following code from the gist below to a file called  post-commit in your repo’s ~/.git/hooks/ folder.

Step 3: Enable permissions

Lets give the file some permission (making it executable by everyone).

sudo chmod +x ~/.git/hooks/post-commit

Step 4: Start committing and smiling 

On first run, the script will create a folder called commit_images in your repo’s root. Then every time you commit code, a photo is added to the folder and to.gitignore automatically so you don’t have to.

Current Downfall

The only downfall to this solution is you have to add it to each of your git repos manually. So if you have a lot of repos it might be a pain, but then again thats what writing a script is for, right? So behold…the global solution (for new repos)!

Global Solution

1. Enable git templates. This will copy everything in the .git-templates folder to any new git repositories when you git init

 git config --global init.templatedir '~/.git-templates'

2. Create our hooks folder for the post-commit template.

mkdir -p ~/.git-templates/hooks

3. Add the post-commit file in ~/.git-templates/hooks/. We can use the same script from above in step 2.

4. Make our post-commit executable. We are giving it executable permission to all users in this case.

sudo chmod +x ~/.git-templates/hooks/post-commit

5. Start committing and smiling. Every time we  git init, we now have the post-commit hook in all of our new repos.

Nice to Have

Here are some things I am looking into:

  • Store pictures from all repos into one folder instead of in each individual repo. eg. in ~/.commit_images
  • More to come…

2,5 years on AngularJS – Part 1

Unbenannt-1

As far as I can remember the first version of AngularJS I’ve ever tried was vegetable-reanimation (released Jun 30, 2011). I was doing some research for my master thesis in those days. After developing web stuff for more than a decade, I dunno way, but I was blasted from day one. So Angular was the framework I used for the master thesis (a webbased car infotainment system).

Afterwards I got the chance to join a kind of “new” team inside the Bechlte corporation where I saw the chance to continue working with AngularJS. The the new team was formed to build a internal product called COPE (content object processing environment). It’s a “homebrew” solution for the corporations catalog production (yes we still print dead trees :) ). But the system is planned to become the central media- & content production/delivery plattform… We will see ;)

I was able to convince the team to bet on AngularJS  and for most of the frontend stuff. This was in 2012 when AngularJS wasn’t as popular as it is today.

We took the opportunity and started with NPM for package management and GruntJS as the build system. The application itself is written in LESS and CoffeeScript. It now consists of:

  • 11416 total lines of CoffeeScript (I reaaaallly like to NOT write  that much code)
  • 7677 total lines of LESS
  • 7000 total lines of HTML
  • which results in about 1,2 MB of frontend related code.

On top there are some libraries and dependencies managed by the awesome bower.

In AngularJS terms, this is 111 custom directives, 45 services, 39 view controllers and 18 custom filters.

Unfortunatly, only the filters and some services are currently being covered by unit tests. This is something I really want to push forward over the next couple of months.

http://www.bennadel.com/blog/2439-my-experience-with-angularjs-the-super-heroic-javascript-mvw-framework.htm
http://www.bennadel.com/blog/2439-my-experience-with-angularjs-the-super-heroic-javascript-mvw-framework.htm

The build system and of course AngularJS enable us to push out features in a way, I never would have dreamed of before. Most of stuff demanded by the business can be implemented in next or no time.

A feature a day, keeps the business away.

 

I will try to do some more blog posts over the next couple of weeks. There I want to give some insights on how we use AngularJS and how solved some nasty problems.