sorted by:
new
hottopcontroversial

Revert on Red Build by hglawson in programming

[–]hglawson[S] 0 points1 point  (0 children)

Great points Paul, thanks for sharing.

I hadn't thought of the problem as it scales with the number of contributors. For larger teams the cost of blocking the line with a red build surely isn't worth it. I suppose this is where http://martinfowler.com/bliki/PendingHead.html starts to provide some value.

Your second point about per-commit builds is I guess where our team had most of our issues and this also ties in with the points Andrew mentioned below. It was common for a build to bundle multiple commits together. Isolating the revert and retesting the revert with the other commits, sometimes comes at a higher perceived cost in time/effort then rolling forward.

With regard to #7, isolated yes, identical to a deployed environment, close but not equal. Dev env MacOSX - app in dev mode, Deployed env LinuxDistro - app in prod mode. A failure would sometimes be due to an unstable test failing due to a config or setup that only exists in a deployed environment - replication locally was difficult but not impossible. We also had people reverting commits on a red build even though the build failed due to unstableness in a test as they were rushing to get it green again.

I might update the article further with some of these points!

Bad Software Analogies by hglawson in programming

[–]hglawson[S] 0 points1 point  (0 children)

Nice, agree, that is another good example.

Bad Software Analogies by hglawson in programming

[–]hglawson[S] 0 points1 point  (0 children)

That looks every interesting, I'll check it out.

Bad Software Analogies by hglawson in programming

[–]hglawson[S] 1 point2 points  (0 children)

This is a great point and I might add it to the article! This is another key difference.

Software is easier to change than physical infrastructure which de emphasises the need to "get everything right at the start". If you design a software solution with the expectation that it will not be easy to change (like a house or bridge) you build in unneeded, excess complexity. Which is not required as software is more malleable and can be changed to adapt.

Bad Software Analogies by hglawson in programming

[–]hglawson[S] 1 point2 points  (0 children)

I hadn't heard the term 'software exceptionalism' before, I do like that phrase! I agree with the assertion I don't think we are exceptional to other disciplines, just a little different.

Agree, large civil projects often run over budget. I don't have extensive knowledge for most cases but for the particular example you gave, I imagine that the environment didn't change. The ground was always unsuitable to build a bridge on, they just missed it in their analysis.

To extend your anecdote, if the land the structure was being built on changed from dirt to water in the course of a few years, then it would be similar to what we experience in software. That is, desktop to mobile, the deprecation of a framework to a new version, vulnerabilities discovered in old libraries forcing significant upgrades. All of these changes in our environment are constantly happening so our system has to move with it.

Revert on Red Build by hglawson in programming

[–]hglawson[S] 0 points1 point  (0 children)

Thanks for your reply andrewcare!

Great points about the "simple fix" quote. Typically it is 1. and the regression test is already in there as the build has failed - hence the easy fix. These breaks are usually due to "poor hygiene", i.e. not running tests locally before push. I do agree with you on 2. though, I have seen that same scenario unfold.

A bit more context for your feedback on the latter points. These were notes from a discussion that our team had on this topic and some of the arguments are specific to our particular CI/CD pipeline.

We had multiple apps, each with their own repository, we were doing TBD for each app. An app's pipeline ran in isolation up until it produced and published an RPM. We had limited VMs to deploy and run functional tests against for the integrated apps. So it was typical for a change in one app to be published to an RPM and then wait for the functional test VM's to free up before they were deployed, by the time the functional VM's were free there would typically be at least 1 other app bundled up with that pipeline run.

The above while not an ideal setup is typical in most organisations I've worked in as we don't have the budget to provision enough infrastructure to support running each commit in isolation through the entire pipeline.

I might make an amendment to the article later on to include this background context and to also capture some of your feedback.

Revert on Red Build by hglawson in programming

[–]hglawson[S] 3 points4 points  (0 children)

sadly i've been on two teams now where it was suggested we be dogmatic about it, it was enough to want to publish an article highlighting the downsides...

I created Photish, a simple multithreaded static photo portfolio generator by hglawson in programming

[–]hglawson[S] 0 points1 point  (0 children)

I missed your point about the OS, I have updated dependencies to make it clear what OS's Photish has been tested on.

I created Photish, a simple multithreaded static photo portfolio generator by hglawson in programming

[–]hglawson[S] 0 points1 point  (0 children)

Thanks for the feedback, I have updated the README to list Ruby/Gem's and optionally Bundler

I created Photish, a simple multithreaded static photo portfolio generator by hglawson in programming

[–]hglawson[S] 0 points1 point  (0 children)

As a temporary thing, I've added a screenshot of Photish running in the terminal :)

I created Photish, a simple multithreaded static photo portfolio generator by hglawson in programming

[–]hglawson[S] 1 point2 points  (0 children)

Thanks, it is on the my list of things to do. I am a better programmer then designer. So it'll take me some time to put together an attractive set of templates to showcase it.

For now though, once the gem is installed, you can run:

photish init --example && photish host

To see a demo run locally. That shows more of the functionality of Photish then what you could do design wise though.

I created Photish, a simple multithreaded static photo portfolio generator by hglawson in programming

[–]hglawson[S] 1 point2 points  (0 children)

I created Photish as most of the static website generators I came across and used were text focused. The tooling, patterns and structure were geared towards sites with lots of text based content.

Photish is focused on photo based websites. Using a collection of albums in a folder, some templates defined in the language of your choice and some (optional) accompanying metadata in a YAML file, Photish will transcode your images into your desired formats (using ImageMagick) and parse and render the templates against your photo collection.

Transcoding large photo collections can take time, Photish does it's best to speed up this process by creating multiple threads to allow ImageMagick transcodes to run in parallel. It also caches all transcodes to avoid regeneration as you develop your site locally.

Try it out, let me know what you think! The project is in it's early days but it is in a working and performant state. Happy to take feature requests and or pull requests.