v2.0 Offically Scuttlebutt doesn’t support posting from the same identity on multiple computers (as of Dec 2017). Unofficially, it’s easy but requires a little bit of care. In practice this means never run the Scuttlebutt client on two computers at the same time. The gotcha is that if you post from both computers before the changes of one have had a chance to replicate to the second via scuttlebutt one or both of your feeds will get screwed up and you won’t see some of your own posts ever again.
Changelogs are an invaluable, and often neglected part of any software project. So, how do you do that? A good changelog helps you users to understand: Why they should care about your latest version If any of your changes affect the problems or frustrations they’ve been having. If there are any changes that might affect how they use your app / library. Why your efforts are worth their continued support.
Let’s start by taking it as a given that a Changelog file is something very valuable that every product should come with. Even if your “product” is a library for other developers. With that in mind, the question rises of “How can I make it really easy to generate one”. Many developers have had exactly that thought. There are many free and some paid solutions that will “Autogenerate your changelog from your git commits/tickets”.
You’ve got a lot of software options when setting up a blog. Over the years. I’ve used or tried most of the options including, but not limited to: WordPress, Jekyll, Octopress, and at least 3 custom built systems. What follows is my thinking on the pros and cons of each option, and why I’m switching back to a static blog system (Hugo this time). Dynamic Blogs (WordPress, etc.) Dynamic blogs, like WP, have a lot going for them:
( as of Sept 30th 2014 ) These are the instructions for how to do it if you’ve already got it configured and need to add a new app / device. If you don’t have it set up already, GitHub’s docs are… probably passable. Go to Settings Click on Security In the “Two-factor authentication” section click “Edit” Yes, even though you don’t want to edit it. Under “Delivery options” click “Reconfigure two-factor authentication Yes, even though you don’t want to reconfigure it.
This afternoon my intern asked me this simple question. She’s a new developer, and a friend of hers is working in a fresh codebase, with best practices. Everything is nice, and he can keep the entirety of it in his head. She’s working with my team, Support Engineering. We’re the front-line bug squashers at our company. We’ve got a legacy codebase with no tests and brain melting insanity around every bend.
This morning’s shower brought me an interesting series of thoughts that I thought you might appreciate, and it all started with the simple question of “How do you set The Atomic Clock?” My first thought was that at some point you have to find some other clock and precisely sync up with it. Then again, they may have said “fuck it” and just had Bob press a button when some other clock flipped over, but then I wondered “How do we know what time it is in the first place?
There are two things that make using vim awesome… no there are about 200,000 but most of them involve adding a few lines to your .vimrc to enable them, or installing a plugin. My .vimrc is just over 300 lines after all these years of use and customization. But, rather than go into all that, I figured some of the vim geeks out there might appreciate a pointer to some of the plugins I use.
Not too long ago I sent out a question. I asked people when, and why, dates were important to them on blog posts. The responses were revealing, both for what they did, and did not contain. There are some situations where having a date on your blog posts is obviously needed. If you write about anything techy you absolutely need them. I come across tons of sites with perfectly good code examples, that have been obsolete for years.
Using Git Bisect …to crush your enemies and/or bugs Or, how to save countless hours and find out where things broke Git bisect is the most awesome, and most poorly publicized feature of git. It allows git to walk through your branch and quickly find out which commit broke things. The usage is simple. You point git to a bad commit ( usually the most recent one ) and you point it to a good commit (the most recent one you know of when things were working).