When deleting stuff in Git, for instance, branches, or tags, we often come across the solution whereby we do something like the following: git push origin :unwanted-branch or perhaps: git push origin :refs/tags/unwanted-tag I wanted to quickly explain why the colon is there, and it has to do with what Git calls the Refspec. The Refspec. Essentially, the refspec is used to configure which remote resource (e.g. branch, tag, etc.
Moving the codejury blog over to a static form. This is primarily due to reliability and security woes with WordPress, plus the fact that I wanted to move the blog directly to my personal domain, to reflect the newer, more personal nature of posts that I wish to move forward with. Well, and also a bit of geekery enjoyment in using a static web generator.
When designing a REST API for your shiny new server, one of the first things you’ll encounter is the PUT vs. POST decision. Precisely, when you’re thinking about how to tell your server to create or update a resource, you’ll be deciding whether to use: PUT for both POST for both PUT for creation, POST for update POST for creation, PUT for update At least, when first starting out with REST, I faced the challenge.
On the server side: Go web server Go is a new language by Google, and it is getting something of a following in terms of being used to develop web servers. There are a bunch of Go webserver frameworks, akin to Rails for Ruby, Django for Python, Node.js, and so on. The main ones at this point are: Beego, Revel, Martini. Whether to use these frameworks or not is your choice.
Recursion is often taught as something that goes along these lines: Base case (or termination case) Recursive step Or really some variant of that. Now, to me, that’s a bad way of thinking about it. It’s a very accurate way of thinking about things, because it’s incredibly general. So it’s correct. But it’s not a good way of thinking about recursion. It hardly makes you feel the recursion.
As far as default window management and Mac’s OS X goes, my opinion is that it’s a sad, sad state of affairs. For all the design sense that Apple has, it strikes me that managing windows on OS X is a painful, frustrating experience. And that’s using the awesome mouse and/or trackpad that Apple came up with. If you’re trying to use the keyboard to handle your windows, you’re basically tough out of luck.
CreateProcess() is simply annoying to call, because of the need to create the input and output structures that CreateProcess() expects. Namely, PROCESS_INFORMATION and STARTUP_INFO. Putting this up as a convenient point to grab code that calls CreateProcess(), and at the same time, short documentation so that the purpose of the dozen parameters are fairly obvious. Mainly for myself, and anybody who finds it useful to grab. Short version: /* Easy Call CreateProcess.
Who has time to bang out /usr/libexec/locate.update? sudo ln -s ~/updatedb /usr/libexec/locate.update The little things.
This post is meant to chronicle my journey into exploring the Mac, and all that it stands for. The Mac that I’m referring to, in this case, is the desktop/laptop that Apple makes, in the form on the MacBook, the iMac, the Mac Mini. Basically, computers. And in other words, not the mobile iDevices. Jumping in. I bought the MacBook. But I cheated. Basically I Googled lots of information on how to automate and hotkey things in OS X.
Quick post, for my own reference, and also for whoever may happen to wonder about NULL or 0 thread creation times in Windows. So, while instrumenting the Windows kernel, it quickly became clear that some threads were having a creation time of 0. My findings System idle process (PID 0) Windows has a “System Idle Process” (PID 0). For a system with n logical cores, Windows will spawn n idle threads.