Awkward and Proud: Top 10 things GitHub will do with VC Funding
GitHub is getting a round of VC funding. Here are the top 10 things they plan on using the money for.
- Genetically engineer an actual octocat.
- Pay off the anonymous Italian who’s been squatting on “code.it”
- Upgrade Rick Olsen to “technosausage”
- Mojombo will finally buy back the username…
A new way to cancan
Inspired by one of my student’s code, I recently adopted a new way to define authorization with cancan.
Often times, it can be very cumbersome to keep track of all the different resources and roles inside an application. Imagine a hypothetical application that has 3 user roles (admin, employee, and guest). The cancan wiki recommends something like the following:
class Ability
include CanCan::Ability
def initialize(user)
user ||= User.new
if user.role?(:admin)
can :manage, Resource
elsif user.role?(:employee)
can :update, Resource
else
can :read, Resource
end
end
end
This, however, can become quite cumbersome - especially when the roles become very lengthy. You’ll be scrolling the whole way down the page, it’s easy to accidentally overwrite existing rules, and it just plain sucks. Instead, we can break the roles into their own methods:
class Ability
include CanCan::Ability
def initialize(user)
user ||= User.new
begin
send(user.role)
rescue
Rails.logger.error("Undefined role method for role #{user.role}")
guest
end
end
def admin
can :manage, Resource
end
def employee
can :update, Resource
end
def guest
can :read, Resource
end
end
If you have other ways you are using Cancan ability definitions, post a comment!
Endorse me on Coderwall please :)
Quick 960 Grid with SASS
960 used to be hard. I just did it in like 10 minutes. Thought I’d share:
Using SASS, we can quickly create a nice little span#{i} loop:
$content-width: 960px;
#content {
width: $content-width;
.row {
clear: both;
width: 100%;
/* span1 - span10 */
$spacing: 16px; // must be an even number
$padding: 10px;
$spans: 10;
@for $i from 1 through $spans {
.span#{$i} {
float: left;
margin: $spacing $spacing/2 0 $spacing/2;
padding: $padding;
width: $content-width/($spans/$i) - $spacing - $padding*2;
}
}
}
}
Essentially it’s just math, but we are looping 1-10 and creating a span for each of that division. Then, we subtract the margin and padding (all dynamic variables) and we have a pretty nifty generator. You can change the loop and make as many spans as you want!
Alyssa Danesh is my hero
…mostly because she’s the only person who ever reads my blog :(
Semantic Versioning
I’m honestly sick of the discrepancies that exist between versioning. As such, I’m proposing a universal versioning scheme with actual definitions that are easy to understand and follow.
One of the biggest complaints from non-technical users of alpha/beta/release candidate software is “it doesn’t work.” Well duh! The problem is that most users have absolutely no idea what beta even means… and this isn’t their fault, its ours.
I remember when I was younger, Hotmail was cool. Anyone who had an email @hotmail.com was legit. Hotmail was still in beta and Microsoft explained beta as “…fully functional with more features to come!” (ProTip: that’s not what beta means today)
Originally, Alpha releases were meant to be “internal only.” This meant that non-technical people within an organization would try the application. It wasn’t released with bugs; this was purely to get feedback, mostly on things like UI, speed, and usage. However, that was back when people used Waterfall development.
Now with Agile Development methodologies, we involve the client in (almost) every decision. While my opinion on Agile Development is beyond the scope of this article, it has changed the way we think about semantic versioning and releases.
Some people argue that every push to git should be a version bump. You’re a fucking idiot. I’m not bumping 0.0.1 because I changed a fucking CSS style. Quit trying to make your product look updated. Other people you should version bump every time you create a git tag. You’re also a fucking idiot. A tag is like a checkpoint in a video game. A version bump is buying a new game, not a save-state. I digress. However, now we introduced the x.y.z notation that we commonly see in software releases. According to most sources, the breakdown of x.y.z is:
- x - Major
- y - Minor
- z - Patch
This was great… Oh, except no one ever really bothered to define major, minor, and patch… Let’s define them now:
- major - Seriously changed the software such that it’s drastically different from it’s previous versions. If this was a paid product, a major version bump would cost money.
- minor - Added a new feature that significantly improves the product. Alternatively, this could remove a potentially malicious and/or problematic feature.
- patch - Bug fix.
Well that’s nice. Now we have a solid understand of semantic versioning… up until about 5 years ago. Open source exploded (thanks github) around that time. Collaboration became easy, and software projects became highly distributed (thanks git). However, this has caused a huge problem for versioning. It’s caused so much of a problem that we added another fucking dot to versions!
Now, instead of x.y.z, we have x.y.z.α. But α, unlike x, y, and z, is not a number, it’s a word or phrase or convoluted nothingness. Rails is my favorite example of this…
Do we really need another predicate for versioning? Wasn’t 3 enough?
This has caused a LOT of confusion among non-technical people… They don’t know what a release candidate is (rc), nor do they understand alpha, beta, gamma… releases. This additional dot encourages developers to release software that isn’t ready for production! Because… if x = patch, then α = untested, poorly documented, possibly removed feature. AKA non-release.
We seriously need to ditch the additional version and stop releasing buggy software. If it’s not ready, don’t release it. Furthermore, we need to better define things like alpha, beta, and gamma releases. Here’s my proposal (summarized):
- alpha - Never sees the light of day. Don’t publish it. Nothing. A piece of software should be tagged as alpha, but never released. This is the “we finished our wish list, now let’s try and break it (as developers).” I prefer to call this the “edge-case” stage. It’s only for developers. If this is a gem, it does not get published; it is shared via source or tarball. The developer or system administrators install the software.
- beta - Exposed to a small (private) group of users. This may be other developers or users who are specialists in the field of the software. This is tagged as beta, but never released. I prefer to call this the “use-case” stage. It’s only for experienced users (in terms of the speciality of the software). If this is a gem, it does not get published; it is shared via source or tarball. The developer or system administrators install the software.
- gamma - Exposed to an entire organization. This does not apply to all kinds of software, especially open-source. This is tagged as gamma, but does not exist outside of the organization. I prefer to call this the “load-balance-case.” As a developer, you are mass-testing the software for excessive workload, in a real production environment. If this is a gem, it does not get published; it is shared via source or tarball. The developer or system administrators install the software.
- release candidate - Go public.
Now, when you go public, what version to you start with? Try 1.0.0. Move along now.
I got Pez. Fuck you 371. You can’t ruin my day. I got Pez.
Official Winter Project
I am announcing my official winter project - a book entitled “How not to suck at email”. The book will detail various tips and tricks to help you not write awful emails in the personal, startup, business, and corporate worlds. It will examine various aspects of email, the true purpose of email, and ways to curb your awful habits.
If we crop out the fat kid, will it knock the file size down enough?
We have a few gramerical corrections to make.
Client: Could you photoshop it so that I look like less of an asshole?
Me: I’m sorry, how…?
Client: My employees say I look like an asshole in this picture, so take care of it.
Me: Can you ask them how you look like -
Client: Look, my employees are ignorant idiots, just fix it.
Me: Oh, I think I see it now.
I have just popped Alfred v1.0 out on the pre-release auto updater a few hours early so that this build can be verified before the general release later today!
To use the Powerpack with this release, you will need your 1.0 license which will have been emailed to your registered Powerpack email address a few moments ago. You can grab the pre-release from Alfred’s General > Updates prefs!
Cheers and here’s to Alfred v1.0 :)
Andrew
Toys at the Dentist’s office (Taken with instagram)
My name's Seth Vargo. I'm currently an Information Systems major at Carnegie Mellon University. I specialize in security and UI, but I'm capable of doing anything.
