jm + dev   24

GTK+ switches build from Autotools to Meson
'The main change is that now GTK+ takes about ⅓ of the time to build
compared to the Autotools build, with likely bigger wins on older/less
powerful hardware; the Visual Studio support on Windows should be at
least a couple of orders of magnitude easier (shout out to Fan
Chun-wei for having spent so, so many hours ensuring that we could
even build on Windows with Visual Studio and MSVC); and maintaining
the build system should be equally easier for everyone on any platform
we currently support.'

Looking at http://mesonbuild.com/ it appears to be Python-based and
AL2-licensed open source.

On the downside, though, the Meson file is basically a Python script,
which is something I'm really not fond of :( more details at http://taint.org/2011/02/18/001527a.html .
meson  build  coding  dev  autotools  gtk+  python 
9 weeks ago by jm
Working with multiple AWS accounts at Ticketea
AWS STS/multiple account best practice described
sts  aws  authz  ops  ticketea  dev 
9 weeks ago by jm
Pipeline Development Tools
"pipelint.sh" -- command line Jenkins pipeline linting
pipelines  jenkins  ci  coding  dev 
11 weeks ago by jm
Developer Experience Lessons Operating a Serverless-like Platform at Netflix
Very interesting writeup on how Netflix are finding operating a serverless scripting system; they offer scriptability in their backend and it's used heavily by devs to provide features. Lots of having to reinvent the wheel on packaging, deployment, versioning, and test/staging infrastructure
serverless  dependencies  packaging  deployment  versioning  devex  netflix  developer-experience  dev  testing  staging  scripting 
july 2017 by jm
DevelEire
Subreddit devoted to becoming a software developer in Ireland, with a decent wiki
ireland  dev  jobs  coding  via:its 
november 2016 by jm
CD at LMAX: Testing into Production and Back Again
Chock-full of excellent build/test ideas from LMAX's Continuous Delivery setup. Lots of good ideas to steal
testing  lmax  build  test  continuous-delivery  dev 
may 2016 by jm
The Challenges of Container Configuration // Speaker Deck
Some good advice on Docker metadata/config from Gareth Rushgrove
docker  metadata  configuration  build  devops  dev  containers  slidfes 
may 2016 by jm
It's an Emulator, Not a Petting Zoo: Emu and Lambda
a Lambda emulator in Python, suitable for unit testing lambdas
lambda  aws  coding  unit-tests  dev 
october 2015 by jm
Hologram
Hologram exposes an imitation of the EC2 instance metadata service on developer workstations that supports the [IAM Roles] temporary credentials workflow. It is accessible via the same HTTP endpoint to calling SDKs, so your code can use the same process in both development and production. The keys that Hologram provisions are temporary, so EC2 access can be centrally controlled without direct administrative access to developer workstations.
iam  roles  ec2  authorization  aws  adroll  open-source  cli  osx  coding  dev 
october 2015 by jm
How IFTTT develop with Docker
ugh, quite a bit of complexity here
docker  osx  dev  ops  building  coding  ifttt  dns  dnsmasq 
october 2015 by jm
Notes on Startup Engineering Management for Young Bloods
Below is a list of some lessons I’ve learned as an startup engineering manager that are worth being told to a new manager. Some are subtle, and some are surprising, and this being human beings, some are inevitably controversial. This list is for the new head of engineering to guide their thinking about the job they are taking on. It’s not comprehensive, but it’s a good beginning.
The best characteristic of this list is that it focuses on social problems with little discussion of technical problems a manager may run into. The social stuff is usually the hardest part of any software developer’s job, and of course this goes triply for engineering managers.
engineering  management  camille-fournier  teams  dev 
october 2015 by jm
Let a 1,000 flowers bloom. Then rip 999 of them out by the roots
The Twitter tech-debt story.
Somewhere along the way someone decided that it would be easier to convert the Birdcage to use Pants which had since learned how to build Scala and to deal with a maven-style layout. However at some point prior Pants been open sourced in throw it over the wall fashion and picked up by a few engineers at other companies, such as Square and Foursquare and moved forward. In the meantime, again because there weren’t enough people who’s job it was to take care of these things, Science was still on the original internally developed version and had in fact evolved independently of the open source version. However by the time we wanted to move Birdcage onto Pants, the open source version had moved ahead so that’s the one the Birdcage folks chose.


(cries)
tech-debt  management  twitter  productivity  engineering  monorepo  build-systems  war-stories  dev 
september 2015 by jm
Introducing the Software Testing Cupcake (Anti-Pattern)
good post on the risks of overweighting towards manual testing rather than low-level automated tests (via Tony Byrne)
qa  testing  via:tonyjbyrne  tests  antipatterns  dev 
september 2015 by jm
Docker image creation, tagging and traceability in Shippable
this is starting to look quite impressive as a well-integrated Docker-meets-CI model; Shippable is basing its builds off Docker baselines and is automatically cutting Docker images of the post-CI stage. Must take another look
shippable  docker  ci  ops  dev  continuous-integration 
august 2015 by jm
Git team workflows: merge or rebase?
Well-written description of the pros and cons. I'm a rebaser, fwiw.

(via Darrell)
via:darrell  git  merging  rebasing  history  git-log  coding  workflow  dev  teams  collaboration  github 
june 2015 by jm
[Nix-dev] Pulling a programs source code from a git repo
Nix supports building from git sha. excellent
nix  packaging  build  dev  ci 
march 2015 by jm
/dev/full - Wikipedia, the free encyclopedia
This is handy!

'In Linux, /dev/full or the always full device[1][2] is a special file that always returns the error code ENOSPC (meaning "No space left on device") on writing, and provides an infinite number of null characters to any process that reads from it (similar to /dev/zero). This device is usually used when testing the behaviour of a program when it encounters a "disk full" error.'
dev  /dev/full  filesystems  devices  linux  testing  enospc  error-handling 
november 2014 by jm
Vagrant and Chef to provision dev test environments
We have recently switched from a manually configured development environment to a nearly fully automated one using Vagrant, Chef, and a few other tools. With this transition, we’ve moved to an environment where data on the dev boxes is considered disposable and only what’s checked into the SCM is “real”. This is where we’ve always wanted to be, but without the ability to easily rebuild the dev environment from scratch, it’s hard to internalize this behavior pattern.
dev  osx  chef  vagrant  testing  vms  coding 
june 2013 by jm
Videos from the Continuous Delivery track at QCon SF 2012
Think we'll be watching some of these in work soon -- Jez Humble's talk (the last one) in particular looks good:

Amazon, Etsy, Google and Facebook are all primarily software development shops which command enormous amounts of resources. They are, to use Christopher Little’s metaphor, unicorns. How can the rest of us adopt continuous delivery? That’s the subject of my talk, which describes four case studies of organizations that adopted continuous delivery, with varying degrees of success.

One of my favourites – partly because it’s embedded software, not a website – is the story of HP’s LaserJet Firmware team, who re-architected their software around the principles of continuous delivery. People always want to know the business case for continuous delivery: the FutureSmart team provide one in the book they wrote that discusses how they did it.
continuous-integration  continuous-delivery  build  release  process  dev  deployment  videos  qcon  towatch  hp 
may 2013 by jm
12 DevOps anti-patterns
my favourite:

3. Rebrand your ops/dev/any team as the DevOps team

CIO: “I want to embrace DevOps over the coming year.”

MGR: “Already done, we changed the department signage this morning. We are so awesome we now have 2 DevOps teams.”

Yeah great. And I bet you now have lots of “DevOps” engineers walking round too. If you’re lucky they may sit next to each other at lunch.
devops  ops  dev  company  culture  work  antipatterns  engineering 
april 2013 by jm
SpaceX software dev practices
Metrics rule the roost -- I guess there's been a long history of telemetry in space applications.

To make software more visible, you need to know what it is doing, he said, which means creating "metrics on everything you can think of".... Those metrics should cover areas like performance, network utilization, CPU load, and so on.

The metrics gathered, whether from testing or real-world use, should be stored as it is "incredibly valuable" to be able to go back through them, he said. For his systems, telemetry data is stored with the program metrics, as is the version of all of the code running so that everything can be reproduced if needed.

SpaceX has programs to parse the metrics data and raise an alarm when "something goes bad". It is important to automate that, Rose said, because forcing a human to do it "would suck". The same programs run on the data whether it is generated from a developer's test, from a run on the spacecraft, or from a mission. Any failures should be seen as an opportunity to add new metrics. It takes a while to "get into the rhythm" of doing so, but it is "very useful". He likes to "geek out on error reporting", using tools like libSegFault and ftrace.

Automation is important, and continuous integration is "very valuable", Rose said. He suggested building for every platform all of the time, even for "things you don't use any more". SpaceX does that and has found interesting problems when building unused code. Unit tests are run from the continuous integration system any time the code changes. "Everyone here has 100% unit test coverage", he joked, but running whatever tests are available, and creating new ones is useful. When he worked on video games, they had a test to just "warp" the character to random locations in a level and had it look in the four directions, which regularly found problems.

"Automate process processes", he said. Things like coding standards, static analysis, spaces vs. tabs, or detecting the use of Emacs should be done automatically. SpaceX has a complicated process where changes cannot be made without tickets, code review, signoffs, and so forth, but all of that is checked automatically. If static analysis is part of the workflow, make it such that the code will not build unless it passes that analysis step.

When the build fails, it should "fail loudly" with a "monitor that starts flashing red" and email to everyone on the team. When that happens, you should "respond immediately" to fix the problem. In his team, they have a full-size Justin Bieber cutout that gets placed facing the team member who broke the build. They found that "100% of software engineers don't like Justin Bieber", and will work quickly to fix the build problem.
spacex  dev  coding  metrics  deplyment  production  space  justin-bieber 
march 2013 by jm
Microsoft's Azure Feb 29th, 2012 outage postmortem
'The leap day bug is that the GA calculated the valid-to date by simply taking the current date and adding one to its year. That meant that any GA that tried to create a transfer certificate on leap day set a valid-to date of February 29, 2013, an invalid date that caused the certificate creation to fail.' This caused cascading failures throughout the fleet. Ouch -- should have been spotted during code review
azure  dev  dates  leap-years  via:fanf  microsoft  outages  post-mortem  analysis  failure 
march 2012 by jm

related tags

/dev/full  adroll  agile  analysis  antipatterns  authorization  authz  autotools  aws  azure  build  build-systems  building  camille-fournier  chef  ci  cli  coding  collaboration  company  configuration  containers  continuous-delivery  continuous-integration  css  culture  dashcode  dates  dependencies  deployment  deplyment  dev  developer-experience  devex  devices  devops  dns  dnsmasq  docker  ec2  engineering  enospc  error-handling  failure  filesystems  git  git-log  github  gtk+  history  hp  html  iam  ifttt  iphone  ireland  jenkins  jobs  js  justin-bieber  lambda  leap-years  linux  lmax  management  merging  meson  metadata  metrics  microsoft  monorepo  netflix  nix  open-source  ops  osx  outages  packaging  pipelines  post-mortem  process  production  productivity  project-management  python  qa  qcon  rebasing  release  roles  scripting  scrum  serverless  shippable  slidfes  space  spacex  staging  sts  teams  tech-debt  test  testing  tests  ticketea  tools  towatch  twitter  unit-tests  vagrant  versioning  via:darrell  via:fanf  via:its  via:tonyjbyrne  videos  vms  war-stories  work  workflow 

Copy this bookmark:



description:


tags: