•May 21, 2015 • Leave a Comment
Bitcoin is about to make another credibility step forwards with the recent announcement that the New York Stock Exchange will provide a NYSE Bitcoin Index (NYXBT) offering sight into the U.S. dollar value of one bitcoin. It will be interesting to see if NYXBT causes an uptick in interest around blockchain/bitcoin from software engineer in the finance vertical who have historical not had an interest in the peer-to-peer platform.
The main are of interest from my perspective is the algo trading opportunities. There are a number of entry points to algo trading:
- Cloud platform – tradewave and Cryptotrader.
Other reading that may aid – blockchain programming. Clearly the blockchain is core, with Blockchain explorer offering some useful insight.
•May 11, 2015 • Leave a Comment
I recently picked up “Fifty Quick Ideas to Improve your User Stories”. Before I provide some thoughts on the book, its worth stating the obvious: a large number of organisation have their own variant of agile. These variants of agile can be many degrees away from the original intent of agile. Its therefore not surprising that, when reading “Fifty Quick Ideas to Improve your User Stories”, you may find some of the ideas unworkable within your project area.
- Page 10, “If a team passively receives documents in a hand-over…that’s not really working with user stories”. Telling stories is the correct agile approach. Unfortunately, this is often countered when there is a void between the Product Owner and the team. Tension between both parties and ever changing stories can lead to issues, which team then begin to go down the road of lightweight requirements.
- Page 12, The Story card is a token for a conversation.
- Page 14, Change in behaviour is key to aiding the conversation. BDD!
- Page 16, story ambiguity WILL lead to issues :) Consider adding clauses to the story template to aid e.g. “Where as currently…” or “Instead of..” See bottom right hand column for trading story example
Why and What in a story – behaviour and system change
- Page 24, Ensure the story communicates the time constraints of a story
- Page 40, Get global concerns on the table at the start of a milestone.
- Page 48. Names project context, ensure milestones are named appropriately.
- Page 56, consider how to demo a story when you start discussing the demo – end of iteration Show and Tell planning before the work starts
- Page 100, “Detailed estimates work again the whole idea of flexible scope’. “Long-term estimates give the wrong impression of precision.”
Definitely worth he read. I only hope more people read this book, and the education of user story writing continues within organisations.
•May 11, 2015 • Leave a Comment
“LinkedIn serves up resumes of 27,000 US intelligence personnel” article offers insight into how social networks can be used to get access to confidential data – architecture, technology stacks, and more can often be found by piecing together various social data without needing to walk though an office door and ask a single question. As referenced in the article, its worrying to find that the US intelligence community is clearly incapable of keeping “secret codewords and surveillance programs” out of resumes.
Given that financial services is big on keeping business secret, it would be interesting to leverage Transparency Toolkit’s to see what is available :)
•May 11, 2015 • Leave a Comment
InfoQ has an interesting article on “Top 5 Java Performance Metrics to Capture in Enterprise Applications”. Performance has, and continues to be in many scenarios, the last to the software engineering party. Once a team has got over the library sweet shop mentality, hopefully validate their proposed architecture, and ideally gone down an executable specification road, the team often has either completely forgotten about performance, or decided to build a performance framework that has not correlation to the executable specification road used from a feature perspective. You can see the gaping hole :)
Business Transactions provide insight into real-user behavior: they capture real-time performance that real users are experiencing as they interact with your application. As mentioned in the previous article, measuring the performance of a business transaction involves capturing the response time of a business transaction holistically as well as measuring the response times of its constituent tiers. These response times can then be compared with the baseline that best meets your business needs to determine normalcy.
Basic stuff. Time to review if you are not doing this already
•May 5, 2015 • Leave a Comment
Lee Hsien Loong (Singapore’s prime minister since 2004) share the last code he wrote – a C++ Sudoku solver. :)
•May 2, 2015 • Leave a Comment
I recently read Managing Humans. Although classified as semi-fiction, with the names of people all fake, I can only imagine that correlation is high to real events, with anyone who has worked with Rands over the years being able to identify who/what/when from the book :) I suspect many of us have considered writing such a book :)
Here are just a few classic extracts from the book that can liven up your day of “management” madness
- Page 5, the all hands meeting run by the CEO that really doesn’t make a connection with the staff
- Page 8, understand your manager, and what makes him tick ;)
- Page 10, an utter classic in my view. The manager who doesn’t understand what you do, and isn’t an engineer.
- Page 18, Rands Test, 11 possible points
- Chapter 4 – How to run a meeting. Essentially, agenda and referee
- Page 58, Classify the Participants. Although obvious, its worrying how many people don’t get this concept. Pawns and Players – which are you?
- Page 76, Management is chess – enough said!. Understand the consequences, make the decision, move. If you are not in this game, your in the wrong game. Have an “edge”, and understand what “execute” (move) means.
- Chapter 15, great engineers are often promoted to leadership for their hard work. While many succeed, and equal part fails because the skills required to lead are vastly different than the ones required to be an engineer.
- Page 99, advice for maintaining an engineering mindset. I for one have pretty much adhered to this view for the entire history of having direct reports. Enough said
- Page 101, remember what it means to be an engineer. A chap once told me that since he had moved to a management position, he was no longer an engineer. :( I was disappointed with the comment
- Page 113, make great decisions, and take responsibility for those decisions.
- Chapter 19, as a software developer, you are going to get screwed at some point – very true, and not just once.
- Page 119, Rands 1.0 Hierarchy. Some great commentary here, including faking done.
- Chapter 21, Time to Think. Like to commentary on Google 20%, page 138. Its a numbers game of thinking and bumping into stuff.
- Chapter 26, When the sky falls :) War room, Think we’ve all been there a few times on this.
- Page 167, Hacking is important. High-impact, fast-moving and bold barbarian. Game on.
- Page 172, Bored people quit – very true!
- Chapter 34, meeting creatures. Some gems in here – Mr Irrelevant, and The Snake.
- Chapter 39, rules for he reorg.
- Chapter 44, resignation check-list. Rule #4 is mandatory in my view. Rule #6 is just madness to even consider.
Net out, worth a read. Some good pointers, but take them in your context, quoting the book is so not the right thing to do as a leader
•May 1, 2015 • Leave a Comment
Lightstreamer recently published an article on pushing Level 2 market data to a HTML client. An interesting article with offers the read source code and appropriate commentary on how the demo works. What I think is missing, and maybe Lightstreamer can update the article in the future, is in my view the following:
- Performance numbers for both websockets and non-websockets
- Links from the article to other articles Lightstreamer might have on Data Adapter and filtering. Filtering is particularly key when the client (HTML) become overwhelmed with data, and can’t keep up with paints (renders)
- Commentary on disconnect of the client and reconnect and the impact on the market data feed. Likewise commentary on server (adapter death) and the performance of fail-over, recovery
- Bandwidth usage
Overall, an interesting article