AmsterdamPHP meetup on state machines

global_117820162.jpeg

Summer is drawing to a close, join us tomorrow (Thursday, September 17, 2015) at LeaseWeb HQ for the AmsterdamPHP meetup on state machines!

Schedule  

19:00: Welcome Drinks
19:30 – 20:30: Talk
20:30 – 20:45: Raffle
20:45: Social, drinks and Pizza

Talk: State Machines at Telfort

Telfort, a major Dutch ISP, uses php driven statemachines for the automation of their business processes and delivery streets.

In this presentation we will dive into the following topics:
– the use cases for statemachines
– the problems they solve(d) for Telfort
– the design challenges for a php statemachine
– the way they are used by the organization in the broad sense
– tooling for support and visualization
– how it supports unittesting and QA
– process automation using statemachines and message queues
– how it facilitates the complex interactions within the system itself and when interfacing with 3d party operational support systems

Examples will be supported by the opensource php ‘izzum’ statemachine package (https://github.com/rolfvreijdenberger/izzum-statemachine) which is functionally equivalent to the Telfort inhouse statemachine system.

Speaker: Rolf Vreijdenberger

Rolf Vreijdenberger is currently working as the software architect for the Telfort delivery street for the copper and fiber business support systems. He has been working in IT since 2001 when he co-founded creative online agency “De Pannekoek en De Kale”.

Raffle

We got some awesome stuff to give away this month, so make sure you attend another awesome meetup!

Location

LeaseWeb Netherlands B.V.
Luttenbergweg 8
1101 EC Amsterdam
View Panorama

Sign up

Click here to go to the meetup page to sign-up for this event!

Share

What Caine’s Arcade has in common with programming

So, Caine’s Arcade is really old news (from 2012), but somehow I completely missed it back then. I case you did as well: It is a touching short film about a boy that dreams of running an arcade. The short film is here (click image to play):

caines_arcade

If you want to see more, then watch part 2 (click image to play):

caines_arcade_part2

Caine’s story moved me, because he has such a beautiful imaginative mind. It also made me sad. Sad because I realized that I am living in a world of grown ups, that – like me – lost most of their imagination.

Programming fosters imagination

But luckily I have an escape for that: Programming. It allows me to escape to a world full of imagination. I can dream of creating a more efficient Javascript framework or a simpler PHP framework. I can program the game 2048 for use in text mode or a PHP Memcache bundle to make you web application lightning fast. Most people don’t care about this, but that does not matter, because recognition is not what drives me.

The “inventor” feeling

Just like with Caine, not being successful does not matter. That’s because there is a stronger force: The act of creating (and imagining) is a powerful and magical thing. This magic is what motivated me to program computers in the first place. It also is what still drives me to create (software) whenever I can. It is the “inventor” feeling that gets you hooked you when you are creating. And the open-source movement that promotes sharing and world-wide collaboration adds a great extra dimension to this.

I <3 programming!

Share

Object Oriented Programming is exceptionally bad

I quote Edsger Dijkstra (1930-2002), a great Dutch programmer and writer:

Object-oriented programming is an exceptionally bad idea which could only have originated in California.

The 3 promises

Object Oriented Programming (OOP) is promising us:

  1. hide implementation details
  2. optimal reuse of code
  3. hiding state, combining code and data

In my experience Object Oriented Programming Languages are no better at #1 and #2 than procedural languages. And #3 may seem logical as we have data and code. This code manipulates the data that should be in a well structured and preferably standardized format. But combining code and data is in my opinion not always a good idea (more on that later).

Accidental obfuscation

Unfortunately these are the characteristics of many OOP code bases I have seen:

  1. hard to learn
  2. many lines of code
  3. low performance

In most cases we do not need IoC, LSP or even SOLID. We don’t need castles built of (Java) classes. We don’t want to read 10 different classes and interfaces to understand often trivial implementations. Programming is hard enough without people accidentally obfuscating what is going on.

oop_is_bizarre

Nobody complains about OOP like Zed Shaw in the above video from exactly 17:24. Click the image to play the video from that point (takes about five minutes).

Use. Less. Classes.

While Object Oriented Programming may lead to the characteristics described above, software (developers) should focus on achieving the opposites:

  1. easy to learn
  2. few lines of code
  3. high performance

The world seems to realize this nowadays. We see that new non-OOP languages like Rust and Go are emerging, while established OOP languages like C++ and Ruby are struggling. Also, make sure you watch Jack Diederich “Stop Writing Classes” talk from PyCon 2012:


stop_writing_classes

Definitely a video worth watching.  Click on the image above to start the video.

Where we really take it too far

You may argue Object Oriented has its place in some software niches. But in the database world (administrative applications) it has not. A database record is not an object. Data should not (and can not) be abstracted. Object Relational Mapping and object oriented data API’s are taking OOP way too far.

You cannot make abstractions to anticipate on future (data model) changes. How are you going to abstract missing data? Or added data? Versioning an API is fine, as long as the API is not exposing data. Behavior can be versioned and the versions can co-exist. But versioned contracts on data and it’s structure do not make sense to me.

Conclusion

Mixing code and data is not always a good idea. OOP is based on this idea. Therefor do not apply OOP without some critical thinking first.

Further reading

Much more has been said about OOP and it being a bad idea. These links are in no particular order:

If you feel like learning about this somewhat controversial point-of-view, then I recommend you to read the list above.

 

Share

Meta-programming: automate software creation

The secret to success in the business software field is to automate the software creation process. If you do so, you gain a big advantage as you have to program or customize less software than your competition. I have identified three types of meta-programming. They all have their advantages and disadvantages.

1) Higher subject abstraction

You can create software that sells “cars” that has, for instance, a table with “occasions”, containing columns for “brand” and “color”.

You can also make software that sells “products”, that have “properties”. Both could be tables, and there could be a foreign key between them. The properties table could contain the columns for “product” (a reference), “name”, “value” and “required”.

I see this pattern when I look at software that is not specialized for a niche. It is clear that generic web shop software like WooCommerce does not know what the web shop owner is going to sell and thus has no other choice than to generalize. It often also allows you to add “custom” fields, often with cryptic and generated names.

Is this bad? Yes and no. Yes, as this creates complex data structures that do not perform and are hard to understand. No, as you may have to do less software development. So in fact you pay your more effective software development by lower software performance and worse structured data.

2) Higher code abstraction

Programming language constructs like reflections, “generics” in C#, “method_missing” in Ruby, “magic methods” in PHP and “proxy classes” in Java enable programmers to write less code that is more generic or reusable.

Is this bad? Yes and no. Yes, when your code starts to get variables named “instance” and “class” it becomes hard to grasp what it is actually doing. No, as it may actually lead to less and more powerful code. In fact you are paying your more effective software development by less readable and harder to modify software.

The real problem is that this approach becomes really ugly when the software is aging. The code will start to contain lots of exceptions implemented as if/else statements in the wrong abstraction level.

3) Generating the code

When you generate code you can still add exceptions afterwards. Also you can still use specific, readable code and simple data structures for the domain you are automating. This actually gives you the best of both worlds: a ‘natural’ abstraction level for data and code, but still lower software development costs. Yes, it may give code duplication at first, but as soon as the code ages, you will see that the exceptions you will have to add actually justify this.

Another advantage of this method is that it can be applied in any programming language as no special language constructs are required.

Further reading

While you are at it, why not check out Rails 3 Generators: Scaffolding and MVC and Scaffolding for Rails Newbs? I’m sure you’ll love it!

Share

Become a better programmer in 30 minutes

Programmers nowadays should all know these 3 very important rules:

  1. Don’t use floating points for money
  2. Store date/time in “UTC” timezone
  3. Always use the “UTF8” character set

Tom Scott brilliantly explains the above 3 topics in videos that roughly last 10 minutes each. He explains them clearly, with depth and in a passionate way. They are listed below. Start the video’s by clicking on them.

1. Don’t use floating points for money

…never ever…

utf8_video

2. Store date/time in “UTC” timezone

…yes, always…

timezone_video

3. Always use the “UTF8” character set

…no exceptions…

floating_points_video

IMHO every programmer should watch these videos, because they are very educational. And “Yes”, it will takes you 30 valuable minutes of your precious time. But “No”, you will not regret it, because they teach you some valuable and elementary lessons. Lessons that apply on any software project, written in any programming language.

Thank you Tom Scott, you rock! Keep doing videos on your YouTube channel!

Share