MacBook, defective by design banner

Put the knife down and take a green herb, dude.

One feller's views on the state of everyday computer science & its application (and now, OTHER STUFF) who isn't rich enough to shell out for

FOR ENTERTAINMENT PURPOSES ONLY!!! Back-up your data and always wear white.
URLs I want to remember:
* Atari 2600 programming on your Mac
* joel on software (tip pt)
* Professional links: resume, github, paltry StackOverflow * Regular Expression Introduction (copy)
* The hex editor whose name I forget
* JSONLint to pretty-ify JSON
* Using CommonDialog in VB 6 * Free zip utils
* that hardware vendor review site I forget about is here * Javascript 1.5 ref
* Read the bits about the zone * Find column in sql server db by name
* Giant ASCII Textifier in Stick Figures (in Ivrit) * Quick intro to Javascript
* Don't [over-]sweat "micro-optimization" * Parsing str's in VB6
* .ToString("yyyy-MM-dd HH:mm:ss.fff", CultureInfo.InvariantCulture); (src)
email if ya gotta, RSS if ya wanna RSS, ¢ if you're keypadless
Saturday, October 25, 2014

And in today's git hint from StackOverflow, how to set up a fetch-only remote in git:

I don’t think you can remove the push URL; you can only override it to be something other than the pull URL. So I think the closest you’ll get is something like this:

$ git remote set-url --push origin no-pushing

Effective enough hack. ;^)

Labels: ,

posted by ruffin at 10/25/2014 02:00:00 PM
Tuesday, October 21, 2014

From TechCrunch:

"Apple's price of admission for 5K goodness is steep, with prices starting at $2,499 (plus additional fees for custom configurations) but it's worth every penny."

Man, I hate these sorts of pronouncements. $2500 is a lot of money. Good, serviceable (and new) laptops run as little as $250. Lets pretend we're computer shopping, we make forty grand a year, and have kids. Are we really going to part with over five percent of our pretax yearly salary for 3x pixels?

I've heard David Smith and Marco Arment argue for the usefulness of a retina display coupled to a high-powered desktop *for iOS app development*, but I'm pretty sure TechCrunch was assuming a broader audience here.

Worth is a relative term, and one that doesn't belong in even so much as a figurative sense in a trustworthy review. Disappointing.

posted by ruffin at 10/21/2014 12:14:00 PM
Monday, October 20, 2014

I really like git-flow ( I first used it nearly three years ago, and with a team of, for the first cut of the software, only two people. It actually works quite well. The most important thing about git-flow -- or any git workflow -- is how it partitions changes to your code logically. The primary benefit of these partitions to code changes is, I think, the reduction of production code churn, though this "firewalled churn" provides benefits all the way back to your develop branch, which is thankfully protected from wacky coder changes in each of their (my?!) feature branches.

In a sense, you have three protected sections:
1.) The wild west of feature branches, delineated by the develop/nightly branch,
2.) The staging environment, bordered by, in git-flow, the master-as-production branch, and
3.) The "pristine" production deploy, a sort of "one-dimensional"/breadthless section of code.

That's really all you need a code management flow to do. Protect what we're testing internally from the cruft we develop every day. Provide another protected area where we can test and fix what we think is "done". And lastly, provide a protected area for code we think is ready for deployment.

Today, my current team is looking at using GitLab to host projects, and, while looking around their site, I found a blog entry on "gitlab-flow", which, in turn, appears to be building off of the "github flow" discussed here several years ago:
> Both of these issues can be solved easily just by having a much more
> simplified process. At GitHub, we do not use git-flow. We use, and
> always have used, a much simpler Git workflow.

I'm not sure that I buy that git-flow is that difficult and *requires* a script, but fine. This alternative flow seems interesting in that it's trying (if my first read is accurate) to kill the distinction between 2.) and 3.), collapsing 2.), the hotfix, back down into 1.), wild west development, from my "sections", above. As Chacon says in the github flow blog entry, "there is no difference in the GitHub flow between a hotfix and a very small feature."

Anyhow, this is mostly to remind me to come back and take another look, but my initial reaction is that seems to invite code pollution. There are times that you'll take a dirty hack in production to minimize live code churn to keep things running well for your "real" users while you take your time to fix the underlying issues "for real" in feature branches. That is, github flow seems like it might discourage deliberate bug squashing -- if you need a major rewrite to fix a bug in a forward-looking fashion, take the time. And if you're going to argue that github flow allows you to patch quickly *and* again, deliberately, later, I'm going to argue you want the kludge to live *only* in 2. before you find you're breaking windows in ways that, in retrospect, you wish your coders were disciplined enough to ignore in their day-to-day work. They're not. Worse still, is your company? Or does that hotfix-qua-"very small feature" end up living in production and your codebase forever because it's working well enough?

That said, I'm stuck in a location whose proxy isn't letting me see the images from the blog entry, so I might have to take this all with a grain of salt for now. ;^)

posted by ruffin at 10/20/2014 11:13:00 AM
Friday, October 17, 2014

I've been editing a fair bit of Powershell code recently, overly largely in gVIm, then alt-tabbing into a Powershell console (where I type "./scriptToRun.ps1") or to PowerGUI (where I hit [space] for "Ok, reload", and then F5 to run). That's been okay, but I've slowly added Sublime Text 2 back to my workflow, and it seems extensible enough that I could quit the alt-tab, type jive workflow, above.

This is the best quick solution I've found so far, with the caveat that I can't load it up with parameters yet.

To use the new build script, click Tools | Build Systems | PowerShell, which activates the new PowerShell build system. Then press Ctrl+B to execute the build.ps1 script.

That'll execute whatever ps1 is active in the editor at the moment through Ctrl-B, with results spit into Sublime's bottom output window. Not an interactive prompt, but not too shabby for the small investment. Kinda cheating (I'm obviously not building anything), but works.

Labels: ,

posted by ruffin at 10/17/2014 09:27:00 AM
Thursday, October 16, 2014

Playing with Powershell, SourceTree (which doesn't diff UTF-16, apparently), PowerGUI, lots of csv files, and Excel means I'm getting encoding crazy. The more I study, though, the happier I am with the decision to swap SqlDbSharp to UTF-8.

Anyhow, to rosetta stone everything to UTF-8, making SourceTree happy, I'm setting encodings with this in VIm.
set fileencoding=utf-8

(Admittedly, I'd rather be using PowerShell ISE than PowerGUI (the latter, at least, defaults to UTF-16, and I needed an "Add-on" to fix it) but PowerShell ISE doesn't seem to notice when I've edited a file with another editor. PowerGUI does, so it's in the rotation for now.)

I'll probably sum all the crazy Excel/csv encoding stuff I've learned in an exciting future post. Spoiler: What a mess.

Labels: , ,

posted by ruffin at 10/16/2014 11:25:00 AM
Saturday, September 27, 2014

Look, I appreciate that you're trying to save me keystrokes when I type try[tab][tab]. That you put the selection onto Exception so that I can immediately overwrite it is exceptionally thoughtful as well.

But come on, you can just check the prefs to see that I don't want you polluting my source with tab characters. Might be nice if you smart-tabbed[-as-spaces] the try-catch block to the context of the code around it too, you know?

Sometimes I feel you only pretend to care. It's a complicated relationship we have, isn't it? ;^)

Labels: ,

posted by ruffin at 9/27/2014 01:11:00 PM
Thursday, September 25, 2014

Security Experts Expect ‘Shellshock’ Software Bug in Bash to Be Significant -

The mantra of open source was perhaps best articulated by Eric J. Raymond, one of the elders of the open-source movement, who wrote in 1997 that “given enough eyeballs, all bugs are shallow.” But, in this case, Steven M. Bellovin, a computer science professor at Columbia University, said, those eyeballs are more consumed with new features than quality. “Quality takes work, design, review and testing and those are not nearly as much fun as coding,” Mr. Bellovin said. “If the open-source community does not develop those skills, it’s going to fall further behind in the quality race.”

Labels: ,

posted by ruffin at 9/25/2014 11:23:00 PM

Support freedom
All posts can be accessed here:

Just the last year o' posts:

Powered by Blogger