As a developer SSH is something I have to think about maybe once every few months when I’m setting up a connection for someone pairing in tmux for example. Cutting and pasting public keys can cost real time when a line feed gets inserted inadvertently or something gets clipped.
So assuming ssh isn’t working and you can’t connect it turns out there’s a pretty helpful debug mode on the client and the server. For the client you simply add the -v mode and get a pretty good idea about what’s going on:
If that isn’t enough then you can just launch another ssh service on another port in debug mode.
Then you can just connect your client to the debugging server with a port specification:
From that you should be able to get enough information to quickly debug the problem.
(My first experience with SSH was way back in 2000 when our 16 year old Unix sysadmin switched all the developers to SSH from raw telnet overnight because he could. All of us were on Windows or Classic Mac OS back then without any default SSH client software, and it cost us at least a day of pain to get everyone back to work.)
Short conversation at the office today. I declared that I wasn’t a big fan of ternaries and that I typically used them only for simple one line statements and almost never in returns and never nested. One of the developers challenged me on why the ternary operator is frowned on and I admitted I didn’t have much in the way of data. After some digging on the interwebs.
Github’s style guide has the most common approach to the ternary:
“Avoid the ternary operator (?:) except in cases where all expressions are extremely trivial.”
Support for using ternary’s in return statements is generally supported as well. There is general agreement that nesting ternaries is a bad practice. Static analyzers like Rubocop and Checkstyle include checks for nested ternary operators.
Historically ternary operators bothered me because I missed them sometimes when scanning through code. If and else are hard to miss on a quick scan. I’ve adjusted to using them for one simple one liners as the terseness is nice. Nesting them strikes me as abuse, much like single letter variables or predicates methods that have side effects.
I’ve had a pretty good run of luck grabbing a colleague to look at my code. The last four or five times it’s been a classic rubber duck case.
Me: So here I’m stubbing out the partials in this view spec since I only want to test this conditional logic.
Me: So it keeps failing when I stub the partials and pulling the in anyway even though it works in similar cases. See I’m just pulling in ‘/users’.
Me: Oh, I probably don’t need that forward slash in users.
Me: Thanks again.
If you don’t regularly grab someone to look over your shoulder on a frustrating problem, you might want to start the practice. You can even use a real rubber duck and explain it to them, but for me it seems to work better with a real person.
In fact, your own ability to keep up with the latest trends have suffered because only you know how to keep things working. To help manage time, you have implemented universal standards and tried to funnel requests to architecture review boards or other planned meetings. Developers routinely work around the system, complaining that process holds them back, but you know that these things are there for the good of the company so you reinforce the policy to try to keep control.
This is a good general description of several EA groups I’ve worked with in past companies. The EA is often far away from the day to day of development and looks to keep control by implementing layers of controls. Not much different then change control boards that attempt to stop change by adding a meeting/paperwork tax to any request. This is where so many EAs fail to add any value and end up becoming another impediment to producing working software. I hope this is changing as Agile has moved to the mainstream, but I fear it is not the case.
Some consultants at our office needed to be able to roll back a Jenkins project that deployed to staging and production sites in case of an issue. The project had been setup to allow for a typical git checkout and then ended up using a php build tool, phing, to essentially rsync up to the servers.
Turns out ‘Parameterized Builds’ was able to resolve this. It took just a few steps:
- Click ‘Configure’ on the project.
- Check ‘This build is parameterized’.
- Add a String Parameter with the name GIT_COMMIT and a default of ‘master’
- Under Git > Branches to build, add the parameter as $GIT_COMMIT
This allows you to specify the commit SHA for each release. If you need to roll back you just run it with the specified commit SHA. This can be configured to use git tags as well. Inspiration of this came from this post.