•March 8, 2015 • Leave a Comment
General collection of React.js reading material.
•March 8, 2015 • Leave a Comment
Yet again ran into issues using the World Clock experimental feature in Google Calendar. Basically the world clock feature appears to be unaware of daylight saving changes in regions. The latest being the start of Daylight Saving time in the USA. Net out, scheduling a conference call for 1:30pm NYC caused me to miss the call :(
•March 5, 2015 • Leave a Comment
BBVA has made a bold statement about becoming a software company, predominately due to the change in mobile usage. If I recall, Deutsche Bank had grand ideas of creating an internal software company at some point in the past – not clear how well that went.
I wondered what technology BBVA are using for their platform:
build a new customer-centric technological platform, which operates in real time and is also modular and scalable. This platform allows BBVA to develop a new generation of services to compete with new startups and major digital companies.
•March 3, 2015 • Leave a Comment
“Out of the Tar Pit” is an old paper, but worth a read never the less. The paper was picked up in more recent years by Hacker School, and also “10 Technical Papers Every Programmer Should Read (At Least Twice), and more recently, Brian Gesiak.
Since Brian has offered a few interesting call-outs already, I’ll only offer a few additional thoughts/quotes:
Page 1: The biggest problem in the development and maintenance of large-scale software systems is com- plexity — large systems are hard to understand
Page 2: Complexity is the root cause of the vast majority of problems with soft- ware today
Page 10, Complexity caused by Code Volume:
“Many of the classic problems of developing software products derive from this essential complexity and its nonlinear increase with size”
Net out, try and keep systems simple to avoid a complexity death spiral
•March 2, 2015 • Leave a Comment
O’Reilly Radar has an interesting article on event-driven architecture, “Variations in event-driven architecture”. Mark Richard’s eBook is available here if you want the full read.
Its probably worth pointing out that I’ve come across a number of people worried about the number of event queues when using the Mediator topology – a strange thought process in my view unless the architect is proposing to use a single queue for all event types :(
It is common to have anywhere from a dozen to several hundred event queues in an event-driven architecture
Its also worrying that a lot of people forget about the Open Source available integration hubs, and instead just straight into coding their own variant – lack of ROI
The simplest and most common implementation of the event mediator is through open source integration hubs such as Spring Integration, Apache Camel, or Mule ESB.
Its nice to see reference to Space-Based architectures in Mark’s eBook. Its surprising how many people look at me blankly when I mention Space-Based architectures :(
•February 26, 2015 • Leave a Comment
Jay Field’s has an interesting posting on code ownership, “Experience Report: Weak Code Ownership”. “Too many cooks in the kitchen” is unfortunately a problem I suspect we have all seen to many times on medium to large projects. Stating the obvious, encourage consistency on a large code base over n years is difficult – its unfortunate that stakeholders who haven’t come from a software engineering background don’t really grasp the issues of such problems.
Primary Code Ownership approach sounds interesting, and reminds me of similar approaches from n years ago on projects which entailed a small team on the server and client portion of a project, with a primary owner for each team. Clearly splitting a project into microservices style can only aid the project by avoiding a single individual attempting to set and govern code ownership of a large code base.
Its probably also worth noting Chris Conley’s recent comments on paired programming, and the killing of code reviews. I think all to often code reviews are over hyped as a silver bullet solution.
We now fully understand the overhead of branches and pull requests. It’s not just the act of checking out a branch, writing a great pull request or the 200 LOC/hour for the reviewer.
•February 19, 2015 • 1 Comment
Few useful links if your going down the User Story Map road: