An svn users' tale of the Git (bare) learning curve.

Herein lies my woeful tale of Git assumptions and the specters of SVN, rabidly haunting my brain meats with errant lies.

I am an SVN guy. I'll outright admit it not matter how much 1337-credit i lose in doing so (offended? I also hate NoSQL and most of the major frameworks). However, with all you hip kids moving to Git, I felt the need to sip on the purple koolaid juts enough to hold a conversation with you criminally insane miscreants. This is the story how I perhaps sipped a little to much (double entendre!!!).

For those of you who are like me, and looking for a helping hand, i'm going to paste the fuck-off error i kept getting, and how I fixed it (with proper git workflow!):

refusing to update checked out branch: refs/heads/dev

By default, updating the current branch in a non-bare repository is denied, because it will make the index and work tree inconsistent with what you pushed, and will require 'git reset --hard' to match the work tree to HEAD.

You can set 'receive.denyCurrentBranch' configuration variable to 'ignore' or 'warn' in the remote repository to allow pushing into its current branch; however, this is not recommended unless you arranged to update its work tree to match what you pushed in some other way.

To squelch this message and still keep the default behaviour, set 'receive.denyCurrentBranch' configuration variable to 'refuse'.

If you're getting this error, read on! I promise you I have the answer. And not the "oh, just convert it to a bare repo" like the rest of the internet says. They are wrong. Join me in joyous perseverance!

Now, I've used Git on and off for a few years now, mostly to keep track of work on a local machine, however I wanted to implement a Git server that could keep track of a repo/ master branch much like how I currently use SVN. And that, is the beginning of "How I wasted a day of my life, a story of misunderstanding and hardship". I'm talking Ann Frank hardship. And as a personal note to you Git guys out there, DOCUMENTATION! seriously. How in the hell does that error at the top of the page help anyone? How about a "why this is bad" note or link? You wasted a day of my life, and i want it back.

If you meandered like a retard down the same path as me, you probably did the following:

1. make directory on server, and git init
2. add some files, git commit -a
3. make directory on client, and git clone
4. edit files, git commit -a, git push
5. Git sez: "ERROR. YOU SUX. RTFM CUZ UR SHIT IZNT BARE. FUCKIN N00B."

After braving the depths of the internetz, I came across a cult of people explaining that "all you needed to do" was convert to a bare repo, and all would be well. This sounded a tab fishy to me, as up until this point nobody had cared to explain what a bare repo was (as I later discovered, it is just the contents of the .git directory. no browsable file structure). After reading a few websites on Git workflow, and heeding some sage advice from a local development firm (SRT), I bravely decided to abandon my SVN knowledge, and start playing with branches. Here is what i found (and what fixed my problem).

Create a git repo on your "Host/Storage Server":

mkdir repo

cd repo

git init

At this point, you have an empty master branch, so lets add a blank file (or copy your own files in to the dir at this point), and commit it.

touch README

git add *

git commit -a -m "here is my first commit"

Now at this point, if we were to clone the master, edit README, and commit from another machine, you'd get the fuck-off error ourlined above. So instead of fighting Git, lets place nice. Following the git workflow, you shouldnt be doing development directly in to your master branch (as it awkwardly attempts to point out in the error message). Instead, the master branch should only be deployment-ready versions of your code (ie: SVN tags). So lets add a branch in which we'll be doing some of our development:

git branch dev

Ok, now head over to your "Client/Dev Server" and clone the repo. I use ssh as a transport because its simple and I like that, but if you want to get all difficult and fancy, you can use the git-daemon which implements the git:// option (which is just ssh on port 9140 or some shit, so I would suggest the simple, cool-guy way, which is ssh).

git clone ssh://username@ip.or.fqdn/path/to/repo

git branch dev

git checkout dev

At this point, you have a full working copy of the git repo on your machine in which you have created and started work in the dev branch (like we made on our server). You can now feel free to mess up the joint by committing or editing files. Then simply:

git commit -a

git push

Bam! you have yourself a hosted Git server! Now that you have your working setup, I would suggest you read over this handy workflow which will help you further understand / make user of Git.

Social Landscape (mental vomit)

These are just some thoughts i wanted to get out somewhere. I did not edit this post, so you may contract ADD by reading it. Consume at your own risk.

Social networks face problems

Signal to noise ratio.

There is no way (easy) to filter data on your needs. I assume facebook is heading in this direction based on their recent classification of all things on their website, but twitter still relies on their archaic text search, which forces the user to consciously decided what they like (every time they look to be entertained), and search for it. They build a way to create lists (predefined ways to sort data) but seriously, who uses these? The solve for this problem would be to predict what the user enjoy (not just what bands they like, but what interests them on a core level, ie: extroverted, or introverted personality types?) which poses a different problem; how do you categorize all human interest? If you apply scope to the interest (ie music) you can classify the data (music) itself, and deliver content based on what they enjoy such as the pandora model, but even pandora requires the user to train the system. The golden ticket is to develop a system in which the users navigation and every day usage defines their interest dataset. After all, our actions are based entirely on our interests.


Interface for input.

A sale is nothing more than convincing someone your item/service is worth the exchange of their effort (be it effort as work, turned in to money, or effort in buying the item itself). I recently spent a great deal of effort (time, energy, and money) on a house. It is something that I clearly use every day, and enjoy very much. It was worth it. When purchasing an item thats worth very little (an mp3 or trinket costing less than $3), we're working on such a small scale that the money doesn't really enter in to it. The effort of filling out personal information and clicking through a payment system is tedious, and will drive people away (unless you compensate with a lower price, ie: a $0.25 mp3, which is what a lot of websites will do, however this only works on a small cross-section of people that consider that effort to be worth $2). The resolution for this is an easy checkout. Systems like Amazon and iTunes have this down to one click, which is why they are wildly popular. These websites sell a direct item or service, but a social network is no different. Instead of working with a monetary value, social networks ask for effort in its purest of forms. Currently, these systems have multiple, relatively easy methods for direct user input, however it seems they have reached their limit.

The golden ticket here, is increased payout (currency or effort) to the user. Foursquare is a system that requires users to "check in" to their location via a mobile phone application. The trade off for this effort is gaining badges (a virtual, solid asset currency) and alerting friends of their location. This system is in contrast to google latitude, which is a completely passive system (zero currency, zero effort) which rewards your user very little. There is no gain of virtual currency such as badges or points or even archival data (which can be trended, offering the user a log of places they have been, ie: effort). Another danger lesson to learn from this example is: you must have both sides of the scale. Creating a system that is 100% free (zero currency, zero effort) does not offer a sale. A trade must take place for the user to feel achievement. In summation, the trick is to create a trade, in which a users effort is worth less than the value of the item/service/data.


How to Capitalize

The goal for the company should be to make money over time, by increasing payout (virtual rewards) while attempting to charge the user a monetary value. Facebook attempts this by allowing the user to purchase virtual gifts for their friends. That reward isnt all that great, so its not a very big success. Online games such as Gunbound have been offering a free game model with purchasable shortcuts (ie: weapons that can be obtained in the game) for years. This model has not only proven itself useful, but is beginning to bleed over in to the larger markets, where games such as World of Warcraft offer special pets or items that are only available for purchase for a $10-$15 fee. Even Console games such as Modern Warfare allow users to purchase new maps to play, or even clothes that they can wear in the game. In both cases, these items do not offer a strategic advancement, yet offer a social clout or bragging rights (ie: attention).

Standing on the shoulders of giants.

To the new developer, social networking sites should be viewed as content delivery networks based on a scale of real-time to archival.

Build a system that takes advantage of the lacking in some systems. A service that archives tweets, and provides badges base on keywords, retweets, or application usage. The badges and or point system would be the reward, but the input is passive, which is 100% free. This poses a problem. We need to create a small amount of work so we have a sale. We can force our users to work (farmville: your plants are dieing), nag our users into working based on new users (mafiawars: your friend needs your help in a mob fight), or create a environment in which your rewards are not just a horde of collected trinkets, but a full currency in which they can be traded. The only problem with that is you are offering your users a get rich quick scheme (by retweeting over and over to gain points).

(this is where i began to teeter off, and get bored of my own post)

Twitter = real-time
Facebook = text:real-time, pictures:real-time/archival

Value to the user:

Attention:
- twitter
- facebook feed
- facebook photo tags

Productivity:
- Farmville: productivity (viewable as a farm) achieved through effort
- Mafiawars: productivity (viewable as stats) achieved through effort
- Online gambling: productivity achieved through risk and ability

Monetary:
- A few websites have tried to pay users for their content in the past, but no names come to mind. (mostly because they failed due to the payout being less than the effort to generate the content)

The Hypogeum PHP Framework

I finally finished the one to many workings of the PHP Framework (Hypogeum) I am building. The framework is geared to be simple yet efficent. Each object has a database definition that links it to one or many tables in a database (ie: a user has user info in the "user" table, and the users avatar resides in the "avatar" table). Once defining your user with one simple array, the class autolads your data and gives you all kinds of ways to manpulate that user, including ways to extend your own functions (like a login function) off of the class. Here are a few quick examples as to things you could do with Hypogeum:

// get user with the unique_id of 1 from the database
$me = $c->user(1);

// echo out the users name
echo $me->attr('username');

// write a new user name to memory
$me->attr('username', 'MyNewName');

// save the users new name
$me->save();

Now the neat part is, all of the tables are bound to the same object, so lets say you want to change the users avatar image title, but thats not in the user table! no fear. You have already told the user class that we have multiple tables.

//set new avatar title
$me->attr('avatarTtitle','This is my new title');

//save the avatar title
$me->save();

The class knows that the 'avatarTitle' field exisist in the 'avatar' table, so it writes accordingly. If you have multiple fields with the same name, its as easy as:

$me->attr('avatar.avatarTitle','This is my new title');

The framework knows to look for a period, and try to use that as a table name. If it cannot, it throws an exception. And i know what you're thinking; "what if i put $me->attr('avatar',"x'; Drop Table users;")"? Well, a few things. If you wanna break your own database, go for it. However you wont be able to use my framework. Everything that interacts with the database is made safe via php filtering, but before that it has ot match the Regex that you define for each field.

So far i bet youre saying "big deal. so you can get one user from a table". Heres a few more options:

$us = $c->user->search('Jim');
foreach($us as $key => $val){
echo $us->attr('displayname');
}

This will allow you to search the user table (on the field or fields you have mapped for string seraching) for users with name 'Jim'. Lets say you want to find all users that have the letters "er" in their last name.

$us = $c->user->search('er',true,'lastName');

The second argument in the search method tells the function to perform a SQL Like search. The third binds the search to a custom field (any field mapped to the table).

If you want to find all of the users that are between the age of 18 and 25, you simply:

$us = $c->user->searchBetween(18,25,'age');

if you want to get all of your users:

$us = $c->user->getAll();

Now heres where i get to the awesome part. You can map objects (oe to many) together. Lets say you have a table of user attributes such as "happy, sad, flaky, duck-like, etc..." and you want to map these attributes to a user. With one line of code in the user class:

// table, id to map from, id to map to
map( 'user_attrib', 'user_id', 'user_id' );

you will automaticly map those attributes when you get your user info. so now, when you get your user info, the mapped data comes with it.

$me = $c->user(1);
echo $me->attr('username')." is:\n";
foreach($me->getMapChildren() as $key => $val ){
echo $val->attr('attributeName')."\n";
}

This would output something like this:
Tendrid is:
happy
duck-like
etc...

It only outputs the attributes that match the current users user_id in the attributes table. And yes, it scales. Even if you get all of the users in the database (say you have 1000), that only requires one sql statment. Once it retrieves all of the users, it then performs a second SQL statment based on a list of all of the ids. So even with 1000 users, all having 50 unique attributes, you only have 2 sql statments. Also, if the attribute already exisist in memory (based on the unique id of the class. In this case being attrib_id) then the framework does not include that in the SQL query, instead it just maps a reference to the attribute already existing in memory. This type of read-check occures on all objects. ie:

$c->user(1);
$c->user(1);

Would only result in one SQL statment.

On top of all this sweet stuff, the framework also has an extended layout class which has a template system based on sprintf expressions. Once you define the objects html template, you can simply do this:

$us = $c->user->getAll();
foreach( $us as $key => $val ){
$val->draw();
}

This will pass the objects current parameters into the template, and output the object formatted in the HTML directly to the browser. The draw method even supports custom sub templates (such as different sizes) all of which are indavidaly set.

$us = $c->user->getAll();
foreach( $us as $key => $val ){
$val->draw(SMALL);
$val->draw(MEDIUM);
$val->draw(LARGE);
}

There are a lot more features to this framework, and i will go over them in detail in the future. The framework will eventually live at hypogeum.net but there isn't much there now :)

MORE PARTS!!!

We just put in another order to sparkfun for our upcoming rocket build out:

DC to DC converter module 6A (Count: 4)
XBee Pro 900 XSC RPSMA (Count: 2)
JST Vertical Connector (Count: 10)
GPS Micro-Mini (Count: 1)
Break Away Female Headers (Count: 10)
IC Hook Test Leads (Count: 2)
Breakout Board for MEMs Barometric Pressure Sensor - SCP1000 (Count: 1)
Break Away Headers - Straight (Count: 10)
I2C EEPROM - 256kbit (Count: 10)
Humidity and Temperature Sensor - SHT15 Breakout (Count: 1)
SMA Male to RPSMA Female Adapter (Count: 2)
900MHz Duck Antenna RP-SMA (Count: 2)
2mm 10pin XBee Socket (Count: 8)
Breakout Board for XBee Module (Count: 2)
SCP1000 Gasket (Count: 1)

Some of these things will also be used for the balloon launch that we plan on being a part of later this fall. More to come on both projects as they unfold.

New updates to Lyfe.net

I've implemented a few new features in Lyfe.net over the past few weeks, but I haven't really had time to sit down and clickty-clack out the hows and whys on my keyboard (until now).

Short Urls - We implemented a base 64 (as in a base 64 symbol set, not the encoding mime type), so now urls are weird looking and like 2-3 characters shorter! Thats how you can tell they're fancy. We shorten the URLs by working with a larger symbol set (0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz-_) instead of the expected base ten set (0123456789). This makes a number like 16000000 boiled down to z2G0. We do this for the sake of twitter, and other social networks where text space is vital. We have a test example script available here. Special thanks to Jeff for sassing up the code with bit tricks.

Habla chat - I implemented Habla for those of you who have questions. Im usually available at during the day. Just look for the chat box in the bottom right corner of the screen on Lyfe.net

Social network - Auto posting to facebook and twitter is fully implemented, however there are a couple of bugs with the signup i need to work out (when i get the time).

I will have more to update on Lyfe when i get some time, Unfortunately other projects (such as peoplebacon.com) are taking up a great deal of my time. Oh, and wedding planning has a tendency to monopolize time as well.

-Jim

Quick ignite notes:

Here is a quick list i am throwing together to further inform the visitors of ignite about what it was i was muttering on about up on stage.

The radio I mentioned (which we will be using for our next launch) is an XBee Pro.

The GPS I featured in my slide was the Venus634FLPx, but you may want to go with this product because it is much easier to work with, plus it stores your GPS data onboard (so no need to record the data on your ground station).

I featured 4 cameras all of which had the time laps feature, but was told after my speech that the now famous cannon hacks can work on a broad range of cameras, and one of the features they boast is time lapse photography.

Ignite - Ann Arbor

Five minutes, 20 slides. What would you say?

If you had five minutes on stage what would you say? What if you only got 20 slides and they rotated automatically after 15 seconds? Around the world geeks have been putting together Ignite nights to show their answers.

Ignite was started in Seattle in 2006 by Brady Forrest and Bre Pettis. Since then 100s of 5 minute talks have been given across the world. There are thriving Ignite communities in Seattle, Portland, Paris, NYC and now Ann Arbor.

We invite you to attend the first ever, Ignite Ann Arbor event. You may learn a thing or two, or perhaps even make some good networking contacts.

To learn more about this event, head over to http://www.igniteannarbor.com

Please RSVP at: http://igniteannarbor.eventbrite.com (Space is limited!)
Twitter search term: #ignitea2

How not to live a life of ultimate happiness

Like a raging bull on steroids, i have blindly taken up the task of resurrecting a project of mine, long forgotten by the user base it once had. Lyfe.net was once a very involved vice of mine that monopolized my time to such a degree that i lost sleep due to hallucinations about the project going awry. I will use this blog to illustrate a great deal of mistakes i made in the past, and a personal road map as not to repeat them.

Welcome to my self inflicted blight.

Entry:
My journey started long ago, sometime in January of 2004. I had just purchased my first camera phone (a Nokia 3650; the first camera phone released in North America) and wanted nothing more than to send images directly to my already established blog of daily insanity (neverendingdoom.com). Long story short, i wrote some code, and got it working. Soon after, my blog readers expressed interest in a service so that they could do the same. After some more code pounding, Lyfe.net was launched some time in early 2006. Users could sign up, and send pictures directly to Lyfe.net, or Myspace.

Decay:
As Lyfe.net became more popular, i began to create new features. I was under the impression that people wanted functionality out of a service, (which i now know to be total bullshit. want proof? how many assholes gave a green beer to each other, or threw a snowball at their friends on Facebook vs the people that actually use any of the advanced applications? the numbers are staggering) The first feature i wrote in was a survey application that allowed the user to create a series of questions, then put the survey on their Myspace profile. Once you took the survey, it would save all the answers and show you who your answers were most like. This application failed. In my opinion, it was totally bad ass. I think 6 people created surveys, and a total of 15 people took them. A total flop. So then i moved on to creating a game out of the picture aspect of the website. There was a weekly scavenger hunt to be launched that anyone could join. I was to design the first one, and the person who found all the items in my list and sent them to Lyfe.net first won. Their prize was the ability to design the next scavenger hunt. It was a great idea (and it may even work today) but nobody jumped on board. I equate this mostly to the fact that camera phones were still very early, and people commonly forgot they had the option of taking pictures with their phone. My next goal was to work video support into Lyfe.net, but when i asked my user base for videos to test with, i only received one. I ceased all development on the project the next day.

Resolve:
About a year ago i came up with a fancy idea to implement groups into Lyfe.net. I planned out the implementation, but was pulled away for another project. But now, 5 years after my initial code was written, i have started development yet again on the Lyfe.net project. I have wrangled the other two unfortunate souls i commonly called on for help with the project to put some time and effort into resurrecting this project. Perhaps Lyfe.net was before its time. Perhaps the idea is a total failure and I’m a jackass for not letting it die off, but everyone needs a hobby.