•January 12, 2017 • Leave a Comment
Angular 2 appears to be a breath of fresh air compared to the madness of Angular 1 – $stateProvider was one of those mad features in my view 🙂 Thankfully, with Angular2 we are back into a component world – not exactly sure why we left, given the history of UI frameworks from the Microsoft .NET and Java UI days.
Documentation appears good as one would expect on the angular site, which an architecture overview here. Probably most useful is the cheat sheet. Nice callout to a pattern everyone should be familiar with:
Apply the Single Responsibility Principle to all components, services, and other symbols. This helps make the app cleaner, easier to read and maintain, and more testable.
In the templates, its worth remembers all the HTML5 features available.
•January 11, 2017 • Leave a Comment
Two interesting articles on ING agile/digital transformation:
What digital means:
We’ve digitized our processes to make transactions clear and easy for our customers. We’ve invested heavily in channels and touchpoints with our customers, introducing mobile and other technologies so that we can offer our services 24/7, anytime, anywhere. We’ve invested in analytics and in getting a 360-degree view of customers to better empower them to make important decisions about their financial assets.
Changing the HR process:
Our HR processes weren’t fit for that purpose, so two years ago, we looked outside—specifically, at Netflix and what they were doing. We found the five-stage Dreyfus model,4 which is based on observable behaviors, not the number of diplomas you have. It measures how you acquire knowledge, how you apply it, and how you transfer it across teams and the organization. We defined our own five stages of IT-engineering performance. We involved the engineers themselves in this process. We asked them which areas of knowledge and which competencies they would expect themselves and their peers to have at various levels of maturity.
As long as you continue to have different departments, steering committees, project managers, and project directors, you will continue to have silos—and that hinders agility
one important initiative has been a new three-week onboarding program, also inspired by Zappos, that involves every employee spending at least one full week at the new Customer Loyalty Team operations call center taking customer calls. As they move around the key areas of the bank, new employees quickly establish their own informal networks and gain a deeper understanding of the business
•January 5, 2017 • Leave a Comment
Another interesting read over at Monzo – Laying the Foundation for a Data Team. Hard not to agree with the “Three core principles” listed: Autonomy, Cutting-edge managed analytics infrastructure and Automation. I’m always impressed with the ideals people come up with when given autonomy over data and thought 🙂 Automation and infrastructure (via code) are I think key to any software project, not just data 🙂
Kafka – enough said 🙂 Isn’t is in all data solutions ? “ETL Is Dead, Long Live Streams” discusses Kafka nicely 🙂
•November 8, 2016 • Leave a Comment
Reading “Ethereum Consortium Network Deployments Made Easy” just goes to highlight Microsoft’s blockchain game plan. Some people will have an issue with the fact that its leveraging Microsoft Azure. I’ve not run the template myself, but if the readme is close to reality, then Microsoft have made it incredible easy to get into the blockchain game for companies, and start developing smart contracts.
•November 3, 2016 • Leave a Comment
Recently when doing some investigation into the world of SAML, I found the SAML Chrome Panel useful. Also found “OAuth with SAML2.0 Authentication” help – I particularly like sequence diagrams 🙂
Once the browser has the SAMLResponse post authentication, it will hit the original web server the User Agent was requesting via a POST – make sure you know what URL the browser is POSTing to 🙂
•October 27, 2016 • 1 Comment
Projects often forget about the build/deploy tax. These days its thrown under the DevOps banner, and often being left to the appointed DevOps individual to wade though and resolve whilst the rest of the team stream ahead with adding new features to the product.
Unfortunately, similar to deciding a testing strategy at the start of a project, and evolving the strategy along the road, build/deployment should be consider in the same context.
Specifically, the build/deploy tax is the duration of time (waste) that it costs the team, from “git commit” to deployment of application to an environment e.g. development, UAT, Integration, Production. This tax is often measured in terms of time wasted “waiting for the build/deployment process to complete”.
There are many factors that influence the build/deploy tax, a few of which are listed below:
- Jenkins (CD server) hardware
- Proximity of build assets e.g. locations of source code repository, nexus, npm, docker registry, test/prod environments
- Structure of source code repository and asset deployment
Often the above issues are hotly debated by both the team, IT support and finance. Examples being:
- Source code be in a single repository or multiple (e.g by micro service)
- Monolithic deployment, or deployment based on services that have changed
- Leverage cloud services e.g. DockerHub or run everything within a separate environment e.g. AWS
Unfortunately, there often isn’t a simple solution to many of these problems. AWS maybe right to running all your build/deployment infrastructure, but the last mile to Prod may still be “painful” due to Prod not being in AWS. Maybe this is an acceptable cost?
•October 24, 2016 • Leave a Comment
Great to see another step forwards in real world usage of blockchain -Aussie Bank’s 7000-Mile Blockchain Experiment Could Change Trade.
Commonwealth Bank of Australia, Wells Fargo and Brighann Cotton with this experiment are aiming to reduce the mountain of paper used to track commodity deliveries around the world
As port staff scan the bales, an update to an electronic contract will be triggered, transferring ownership of the goods and authorizing the release of payment. The deceptively-simple sounding process is only possible because digital-ledger technology encrypts and stores the parameters of the contract, ensuring all parties are working off the same synchronized version, which cannot be unilaterally altered or tampered with.
Its also interesting to see Maersk and IT University of Copenhagen undertaking an experiment with blockchain in the bills of lading space.