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 www.myfreakinfirst-andlast-name.com
Using 89% of the same design the blog had in 2001.
FOR ENTERTAINMENT PURPOSES ONLY!!!
Back-up your data and, when you bike,
always wear white.
As an Amazon Associate, I earn from qualifying purchases. Affiliate links in green.
Pricing for GitHub Enterprise starts at $5,000 per 20-user seat pack per year, which includes maintenance, upgrades, and technical support at no extra cost. The calculator below can help you estimate your annual costs for a license.
I'm not sure I understand the appeal of "GitHub Enterprise". Rather, I'm not sure that those who are considering some "enterprise" flavor of git get git.
I mean, the biggest selling point of git is that it's essentially solved the issue of distributed development. There's no reason to pay for phat, centralized management. If you have some strange cesspool of three developers who go off on their own for a year and then check all their stuff back in, git will handle it. You might have to diff conflicts forever and a day, but as wacky a checkin structure as you have is fine by git. If you have thousands of folks checking into the same branch beyond nightly integration, well, you're doing it wrong. Any worst case of forked development isn't a technical issue, it's simply a reintegration headache, regardless of the power of your repo "server".
I mean, you can put git repos everywhere. You don't need one repo to rule them all. It's like a starfish that loses an arm (and *poof*, you've got two Patricks). Everyone's up-to-date workstation has the potential to rebuild your codebase's history in its entirety. Why do you need "maintenance, upgrades, and technical support", at least on the code management side?
Has anyone ever really had unrecoverable trouble when they collaborated over a network drive? Has any team who checked in daily really ever lost significant amounts of code due to git's infrastructure? Gosh, I can't imagine so. If you've got it three or more places, you already have a "living RAID".
Obviously what they're selling is the active directory integration, bug tracking, and perhaps some code review overhead, but if you get your coders used to using git, I swear code management is self-regulating. Budget accordingly. ;^)
I really like git-flow (http://nvie.com/posts/a-successful-git-branching-model/). 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:
http://scottchacon.com/2011/08/31/github-flow.html > 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. ;^)
Finally started seriously scratching a new itch. I really disliked how difficult I'd found it to get a database engine working crossplatform for my C# "hobby" projects with MonoDevelop and, now, Xamarin Studio.
I'd considered using JSON or DataSet's WriteXML method to serialize data, but up until now, I'd been just writing stuff to text files to get hobby projects running more quickly. After using home-grown text file formats for years, though, it seemed dumb not to leverage SQL syntax. Yet every time I tried to find a good, crossplatform solution, I would waste hours not quite finding a great answer.
MVED# was written largely because of setup hurdles encountered attempting to deploy other obvious embedded database solutions for C# crossplatform. SQL Server Express is not crossplatform. SQLite must be installed on Windows and has a few nontrivial setup requirements on OS X, both of which create a clear barrier to entry out of proportion for applications with modest data serialization needs. C#-SQLite is an interesting alternative, but still had issues when I tried it out in May of 2012.
So back in February 24th of this year, I started hacking a database engine. And 121 commits to Bitbucket later, I finally have enough to put up on GitHub. (The GitHub/Bitbucket dynamic is also very interesting...) I can CREATE TABLE, INSERT, DELETE, SELECT, even INNER JOIN. I'm an UPDATE away from 80% of what I use "real" databases to accomplish. Well, if you ignore speed.
It's fun to look back over my commits, as always. There are almost zero commits in June and July, when work took a real turn for the busier. Seems like tons of late night commits. Also some interesting comments about where I was while I was coding...
Admittedly, there are tons of *cough* idiosyncratic behaviors in the engine, but much of this was an enjoyable alternative to the horribly defensive coding you have to do for customer-facing code. If I don't want to support ORs in WHERE clauses yet, well, I don't have to. If I want to support only INNER JOINs at first, that's my "right". Case sensitivity? Whitespace rules? All my decision. Bizarre! Want FLOATs to be stored as conventional DECIMALs for now? No problem (and more accurate too)! Unicode? Not yet! Why not? Because I chose [not] to! I'm drunk with power.
It was a heck of a lot of fun dealing with how to serialize each of the datatypes I'm supporting now. I did take a few old school-ish routes with storage while writing. Every column's length is absolutely fixed (VARCHARs really aren't VAR at all), largely to make the file's format really easy for users to eyeball, probably a leftover from having played around with 6507 assembler too much years ago. I even slap lines of 0x11s between columns to make it super-easy to view. Having easier-to-read files is probably not the best motivation for creating formats, but I'm happy with how it turned out.
Here's a crappy example of a raw "Moore's DataBase File (mdbf)" in the quick file viewer I wrote for the engine (click to see in any real detail).
Figuring out ways to serialize strings and decimal values was, honestly, fun. Doing this without much heavy "cheating" (more accurate would be "researching") was also a refreshing break from "serious" work, as this project is intended to be almost completely for [my] relaxation. Getting close to finished in about a tenth of the lines of C#-SQLite is, well, interesting. There's a lot that's not here. Parsing commands, even when you do get to choose what's syntactically legal, quickly gets, well, ugly. JOINs tend to bust what would otherwise be a pretty simple paradigm for parsing SELECTs -- heck, even SQLite currently doesn't support RIGHT OUTER JOIN. (Actually, reading that page, I feel a little of Hipp's pain (though let's make clear, since I'm talking about both in the same paragraph, that C#-SQLite is a port of SQLite by Noah Hart). GRANT and REVOKE don't mean so much when you're just hitting the file system, do they?)
Ultimately, writing MVED# reminded me a great deal of the shareware app I wrote years back. Eventually, even when you have nobody to answer to, code reaches the point where it's difficult to keep things idealistically organized. (Insert tangent about why it's so much more important to see a candidate's solution to a real-world problem than to simply interview, say, a new graduate about patterns when you're hiring.)
This project was also my first "real-world" use of the GNG Manfiesto. Even though MVED# could have easily gone under LGPL, I think there are going to be times where it's easier to use with the project's files compiled into a single app with new, closed files, so I opted for MPL 2.0 for now. Either way, it's open, demands changes by others to be shared, but allows others to use it as they'd like without compromising their own original, unrelated contributions, just as GNG demands.
Anyhow, to advert a little more plainly, the Minimally Viable Embeddable Datastore in C# (MVED#) or, as I called it as I developed it (since I wasn't worried a whit about performance), Moore's Database, can be found here:
It's not feature complete yet -- I'd like to sneak an UPDATE command handler in there before I do too much clean-up of existing code, which will be an easy refactor and then edit of the SELECT code -- but it's surprisingly close for what I think I'd like to use it for. A quick class for testing should follow UPDATE.
The code is hilariously simple. Optimizations are almost non-existent. Yet, at the same time, I think it's a horribly accessible codebase. We'll see. I'm going to use it. It works just as well on OS X as Windows, and that's a great start for my apps that need an embedded database solution. I can only assume Xamarin's going to make it pretty easy to use MVED# on Andriod and iOS too.
But okay, fine. I hear what you're thinking. If I have 121 commits and each one is, say, 30-45 minutes (let's go on the high side of that range and say 45 min, though admittedly I wonder how good of an estimate that is), that's 90 hours I didn't spend writing The Next Great Piece of Software with an existing engine. And it's not like I'm done yet. To me, that sort of cuts both ways. I'm surprised I'll be able to get a first functioning database engine in well less than three full-time weeks' of work, and I wonder if I'd waste that much time trying to get existing DBMSes working crossplatform. But then if I'd kept development to a primary platform and used the obvious DBMS engine for it, that's ~90 hours of work and months of free time I'd be ahead of where I am now to release an app for someone.
Regardless, it's been, and hopefully will continue to be, a fun project. Happy hacking.
The postings on this site are [usually] my own and do not necessarily reflect the views of any employer, past or present, or other entity. About Our Author
