Comments for Jamie's Blog

Comment on Delivering software continuously and why you should by Cranking up the dynamic environments with Puppet | Jamie's Blog

Cranking up the dynamic environments with Puppet | Jamie's Blog — Sun, 18 Dec 2011 20:37:13 +0000

[...] an advocate of Continuous Delivery, I needed a consistent development and production environment and I didn’t like the idea of [...]

Comment on MQTT Client Library for Delphi by Jamie’s Blog | MQTT Client Library for Delphi « The Wiert Corner – irregular stream of Wiert stuff

Wed, 23 Nov 2011 05:01:49 +0000

[...] Another way to talk to WebSphere MQ from Delphi is to use the MQTT Client Library for Delphi. [...]

Comment on Time to bury this “Is Delphi Dying” nonsense by dennis

dennis — Fri, 11 Nov 2011 12:34:06 +0000

Looks like delphi is dead.
Just because the domains are.

Comment on tgrep challenge by Dorin Duminica

Dorin Duminica — Wed, 26 Oct 2011 02:26:27 +0000

Interpolation search is the way to go IF AND ONLY IF the data is in ascending or descending order.
If the files are huge, then one could read in chunks of a few mega bytes, say 20-25mb(because that’s almost certain that it will load within 1 sec).

Comment on Dynamically compiling code with Delphi Prism by Mark Johnson

Mark Johnson — Mon, 08 Aug 2011 18:36:49 +0000

I recently told to start programming for .NET including for Linux environment. So, I am programming and learning Delphi Prism for the last 3 months. It definitely has been a true learning experience. However, I should give credits to people like you who post very important and great programming articles like this one. Thank you.

Comment on Delivering software continuously and why you should by Gary

Gary — Fri, 29 Jul 2011 00:55:14 +0000

@LDS

True, some organisations require strict regulatatory compliance. In which case, you guys are stuck in the dark ages because of red-tape.

I’ve been in the software business professionally for over 20 years, and none of what’s been mentioned in favour of CD is bad, wrong, or nonsense as you put it.

If there are tests, more tests, and even more tests, to prove something is right then your confidence of the feature being right will naturally be higher than simply pushing a load of code live and hoping that the UAT people covered every angle.

Feature toggles are good.

How many big releases in your career needed to be backed out? What if you could switch the toggle (either on the fly, or through a restart), and everything was back as it was? (OK – there are exceptions to this case) but I think up to 80 of the time this is true.

Once confidence of a feature is 100%, remove the old code, and move on. If you get it wrong the tests will tell you.

What if you could automate the whole release process from one environment to the next, and more importantly, make it reliable and repeatable for each environment, including Production?

Okay, regulatory requirements may get in the way, but hey, look what you gain in other aspects regardless.

This can only happen if you do what hurts often.

It’s not easy to get to this state, but when you do, there’ll be no room for people scratching their backsides.

I hope you’re not one of those people.

Comment on New Goodies in Delphi Prism 2011 by Mark Johnson

Mark Johnson — Fri, 15 Jul 2011 13:52:41 +0000

I agree with Jim Mckeeth. Indeed excellent summary of what’s new in Delphi Prism 2011. Although I am a beginner in this programming playing field, I am learning a lot from blogs like yourself. Thank you and keep up the good work.

Comment on Delivering software continuously and why you should by jamiei

jamiei — Fri, 24 Jun 2011 23:31:06 +0000

@LDS: Regulation is certainly one constraint that may mean you are unable to truly push the last mile everytime. But at least you’d have the systems, practice and testing to ensure that when you do, it is less risky.

Comment on Delivering software continuously and why you should by LDS

LDS — Fri, 24 Jun 2011 21:22:29 +0000

Who said that without CD you *manually* push out releases? You may have CD up to internal test servers, but not beyond. When it’s time to update production server the process is automatic as well – just not “continuos”.
External test servers and production servers may not allow easy CD – especially if you’re in highly regulated environment (and some certification wants it) and you have to approve (or obtain approval for) each change. Adding disabled features is a nonsense to me – just adds complexity and may lead to unwanted risks if enabled by mistake.

Comment on Delivering software continuously and why you should by jamiei

jamiei — Fri, 24 Jun 2011 17:56:50 +0000

@LDS: There are no panaceas but I object to your implication that it is “unplanned” to push constantly. By automating everything, I would argue that it is more controlled than manually pushing out releases, config and data changes.

If a particular feature requires pre-training then add it as disabled and provide some way of enabling it once the training has been undertaken, this was why I mentioned changes in the architecture of the application and feature toggles.

I’m not arguing that there isn’t a possible scenario where CD isn’t appropriate but none of the typical concerns that you’ve mentioned so far are too complex to overcome.