Below are a few notes I took during the global installation process, applied to my reality (Ubuntu), it all went about well the first time, I had built setup related issues (they’re in the notes down there, rookie mistakes and particular conditions) . They’re straight out of my installation process, so there’s no QA assurance on this post :) , either way, along with the website you’ll be fine and on your way with getting the full tool-chain up and running

Installation notes

PEAR phpqatools

sudo pear config-set auto_discover 1
sudo pear install pear.phpqatools.org/phpqatools
sudo pear channel-discover pear.phpdoc.org
sudo pear install phpdoc/phpDocumentor-alpha
sudo pear install channel://pear.php.net/Text_Highlighter-0.7.3

Jenkins

DEB Install

wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add -
sudo vim /etc/apt/sources.list
# Add the following line
# deb http://pkg.jenkins-ci.org/debian binary/
sudo apt-get update
sudo apt-get install jenkins

Template for Jenkins Jobs for PHP Projects

sudo pear install pear.phpqatools.org/phpqatools pear.netpirates.net/phpDox
sudo pear install channel://pear.netpirates.net/phpDox-0.4.0

Jenkins CLI

Had to manually update the Jenkins Plugins DB via the Web interface, the CLI interface doesn’t seem to have an proper command

# Get the jenkins-cli jar file
wget http://localhost:8080/jnlpJars/jenkins-cli.jar

# Install the plugins
java -jar jenkins-cli.jar -s http://localhost:8080 install-plugin analysis-core checkstyle cloverphp dry htmlpublisher jdepend plot pmd violations xunit git 

# Restart Jenkins
java -jar jenkins-cli.jar -s http://localhost:8080 safe-restart

Jenkins PHP Template

My Jenkins Home is: /var/lib/jenkins

cd $JENKINS_HOME/jobs
sudo git clone git://github.com/sebastianbergmann/php-jenkins-template.git php-template
sudo chown -R jenkins:nogroup php-template/

Also, make sure you have ‘ant’ installer

sudo apt-get install ant

Running your first Build

• Build Failure #1 – Clone permission denied
  Some local .git/objects files hadn’t READ permissions for everyone, fixed it with

chmod -R a+r *

• Build Failure #2 – Could not apply tag. Optionally you can do this on the Jenkins Web Interface (job configuration => git => repository browser – advanced button )

  cd $JENKINS_HOME/jobs/project/workspace
  sudo -u jenkins git config user.email "jenkins@localhost"
  sudo -u jenkins git config user.name "jenkins"

At this point, you’re about ready to go, mind you, you have a pretty empty build right there (unless your project is already configured with build instructions of course), in any case, do check out this post since it will absolutely get you going with the proper build steps you need to take.

Now, all we need is quality software

Update #1: @trodrigues provided #tumblr power -> http://thesoftbook.tumblr.com/

Update #2:  @trodrigues combined the power of @ifttt , you can now use the #softbook hast-tag to feed the tumblr blog

Next time you think of posting a silly picture online, say like this one

Beware of what comes next …..

Twitter IS legion my friends

Sleg-dogs by Fritz Hoffmann

I was reading the National Geographic magazine and was blown away with this. If you think your job is though,meet the Sirius Sledge Patrol, a 14 member elite division of the Danish Navy, these guys maintain and patrols the arctic regions of Greenland. They work with two man teams and some patrols take as long as 4 months – 4 months in the middle of the Arctic wilderness, alone with a team mate – and they take dogsleds, because using mechanical devices in the middle of absolutely nowhere for thousands of kilometers is a recipe for, well given the conditions, death, dogs don’t need spare parts and fuel can be found along the way.

IF you want to join the team, you must be a member of the Danish Navy, have an age between 20-30 years and run a 6 month intensive course basically teaching you how to survive the end of the human race and then some, if you manage to get to the end of the course, maybe you’ll get picked for the team, maybe not.

Be sure to read the NG article, it’s an eye opener

Links:

• Danish navy Sirius information (DK only)
• Wikipedia page
• National Geographic article
• Eastgreenland Sirius information
• Danish Channel documentary intro
• Fritz Hoffman’s page

Hint, one is black the other is blue and they all look alike

Now, the list of available options is nothing short of daunting, so I’ll use some biased judgment, a few recommendations and stroll along gathering information and keeping an open mind.

I also watched (finally) these two Codebits presentations and will be including some information along the way – at least as target practice

• The Future of Programming Languages – by Alcides Fonseca (slides here)
• My language is better than yours - by Artur Ventura

This will take a while to filter, so I’m dividing my efforts into iterations and posting them as I go.

The Go programming language

The Go programming language is an open source project to make programmers more productive. Go is expressive, concise, clean, and efficient. Its concurrency mechanisms make it easy to write programs that get the most out of multicore and networked machines, while its novel type system enables flexible and modular program construction. Go compiles quickly to machine code yet has the convenience of garbage collection and the power of run-time reflection. It’s a fast, statically typed, compiled language that feels like a dynamically typed, interpreted language.

I gotta say, it complies with the criteria I mentioned and, it’s ranked below NXT-G so it’s pretty hipster territory right there . It needs further investigation, but it made it to the shortlist.

Go Tips for learners on the road:

• Go-Tour - An interactive in-browser Go tour that you can install and run locally
• godoc , it’s installed with go, just run : godoc –http=:6060

Resources:

• The official Go Site
• GitHub Language Explore for Go
• Go Programming Language Resources

Hello World

package main

import "fmt"

func main() {
	fmt.Println("Hello, 世界")
}

Installing and taking a stroll

The official site has a install reference page, I followed it and I was shocked that everything went smoothly the first time, I mean … there’s no decency anymore. Not only that, but they have the nerve to have a Go Tour (http://code.google.com/p/go-tour/) that you can install locally and run (say when I’m on the train) , where you are presented with the basic information on starting to code in go and where all the exercises are actually compiled on your machine. Pretty Neat.

Languages that are out

Meanwhile, some languages have been looked into and checked against “The Criteria” and are now out of the running – so to speak :

• Fancy - Ruby inter-operable oop language. Benefits from all existing Ruby classes, doesn’t feel like moving to it instead of Ruby would be beneficial for me. The message passing angle I never explored before, but fails criterion #2
• Dart - A “we can fix javascript” attempt by Google . Interesting, OOP style, fails criterion #2 and #5 (I think) – might be interesting as a side tool for writing up “javascript”
• Coffeescript – Doesn’t have behemoth Google behind it, but for now I’m putting it in the same category as Dart

Part #2 of the thinking-out-loud-learn-a-new-language series (Part #1 here)

Ok, so learning a  new language is cool and exciting, but we’re doing it on the run here, full time job (and then some), 2 kids, 1,5 hour (split between 3 stretches) commute time two .. the works , so time is one problem and focus is another, so sort of getting it right from the start is important here. This means I should get some proper metrics and goals for this to work, that my choice needs to be as practical as possible and that whatever it is, it must add a new dimension to what I already know (syntactic sugar aside) and not simply be an alternative to, in this case, PHP.

So, a short list of things that should influence the choice:

1. I use Linux – of the Ubuntu flavor - so proprietary or OS limited stuff is, baring alternatives, out of the question (should I consider Objective-C ? .Net based languages despite having Mono?)
2. Needs to have a wider or different scope than that of PHP – i.e. mostly web of the HTTP flavor – doesn’t necessarily have to do EVERYTHING out of the box, but flexibility is smiled upon
3. Obviously needs to have good official documentation and I would appreciate some liveliness on future developments – stalled “We’re fine this way” languages lose points
4. It’s surrounding tools and infrastructure aspects again, should be available and relatively easy to setup – if the best language in the world requires a HPC infrastructure to get a “Hello world” running, it is most definitely out of the question
5. Must provide drivers and ways to connect to loose infrastructure applications (db’s, web servers, graphic drivers, etc)
6. while syntax and paradigms are not the complete goal here, it shouldn’t be a completely brainfck’ed up language (yes yes a pun there )
7. Having Enterprise written up, left, right and generally all over it is *NOT* a good sign , too

So, yeah, pretty wide criteria here, I might need to narrow the scope a bit, but it will serve me as a sort of checklist that I need to run against. While I will probably return to make the list better, I think I can start shopping around now

Any words on this? Comments? Have you done a similar process and wish to share your thoughts?

• Basic (o the Q, QW and Visual types),
• the Pascal ( the Turbo and the Delphi types),
• the ASM,
• the C,
• the C++ (I could point all the fun we had,but all I have are pointers to pointers and I left my deferring stick in my other pants),
• the PL/SQL,
• the ActionScript (the bleargh, 3 and Flex oriented),
• Ruby (oh my darling),
• Clipper,
• Javascript
• Java

But PHP as been my traveling companion, for no particular reason, from 3, to 4, to the very much welcomed 5 series. I enjoyed the wide support, the magnificent documentation, the easy entry level, it’s ubiquity, it’s presence in hosting services everywhere and having stick with it for so long I saw it evolve over time, bringing new constructs and features to the language (even if never doing away with all of it’s garbage) and while I can’t evaluate how fast or how intensively other languages changed, I was never truly let down by new PHP releases and what they brought along, or will continue to bring.

But still, I had other experiences, Ruby still plagues my PHP experience with it’s 100% oop approach to everything, I love the fact that you can write

"what, a string?".methods.sort

and know exactly what you can do with a string, alphabetically ordered just for my viewing pleasure , I loved how well the mixins worked and how gem’s coming in from everywhere and anywhere would just immediately mingle and turbocharge existing classes (yes, hello PHP 5.4 traits, I know you’re coming) . I used RoR – a bit after the “OMG It’s magic” hype went down, that sort of impossible-to-happen hype really brings out the irrational hate in me – and liked it a lot – I mean, when push came to shove, and complexity came into play, upgrading Rails became less and less easy / possible, without major rewrites (ohh 2.0,2.1,2.2 series), and it was always exciting too see Ruby apps panting with 400MB of used RAM while the equivalent PHP app was flying with 50MB .. but those are infra-structural details that have many strategies in how to overcome .

Anyway, while PHP will continue to play the lead role in my money making abilities, truth is I need to see what’s out there again, I have nagging friends who troll away with ease for my PHP choice of language, not that I put much faith into generalist trolling of the friendly kind, all languages have their ups and downs, and they’re not even bothering to use radically different languages, so I know it’s just PHP punkin’ around , but still, my synapses need the change, I need to experiment with different approaches and so, I need to learn a new language

But what should I choose ……….

(to be continued)

Anyway, my climb out of the hole continues and loose rocks continue to fall on me, forcing me to yet another change in course, so the roughness continues, but my need to bring my brain down to earth and make it more … productive, is increasing exponentially, it’s been 14 months since Child #2 came to be, and the time to do this is now.

This is also a post for myself, the information contained herein is close to non-existent, but it’s 2012, it’s time I have a blog, if you’re out there, thank you for being, don’t shy yourself out of pushing or kicking me in the back of my head, and let’s get this A.D.D. thing under control and see what kind of a human I am capable of being after all.

Onward, to business, life and community success and/or a big ball of fire

This is such a common question here and elsewhere that I will attempt to write the world’s most canonical answer to this question. Hopefully in the future when someone on answers.onstartups asks how to split up the ownership of their new company, you can simply point to this answer.

The most important principle: Fairness, and the perception of fairness, is much more valuable than owning a large stake. Almost everything that can go wrong in a startup will go wrong, and one of the biggest things that can go wrong is huge, angry, shouting matches between the founders as to who worked harder, who owns more, whose idea was it anyway, etc. That is why I would always rather split a new company 50-50 with a friend than insist on owning 60% because “it was my idea,” or because “I was more experienced” or anything else. Why? Because if I split the company 60-40, the company is going to fail when we argue ourselves to death. And if you just say, “to heck with it, we can NEVER figure out what the correct split is, so let’s just be pals and go 50-50,” you’ll stay friends and the company will survive.

Thus, I present you with Joel’s Totally Fair Method to Divide Up The Ownership of Any Startup.

For simplicity sake, I’m going to start by assuming that you are not going to raise venture capital and you are not going to have outside investors. Later, I’ll explain how to deal with venture capital, but for now assume no investors.

Also for simplicity sake, let’s temporarily assume that the founders all quit their jobs and start working on the new company full time at the same time. Later, I’ll explain how to deal with founders who do not start at the same time.

Here’s the principle. As your company grows, you tend to add people in “layers”.

1. The top layer is the first founder or founders. There may be 1, 2, 3, or more of you, but you all start working about the same time, and you all take the same risk… quitting your jobs to go work for a new and unproven company.
2. The second layer is the first real employees. By the time you hire this layer, you’ve got cash coming in from somewhere (investors or customers–doesn’t matter). These people didn’t take as much risk because they got a salary from day one, and honestly, they didn’t start the company, they joined it as a job.
3. The third layer are later employees. By the time they joined the company, it was going pretty well.

For many companies, each “layer” will be approximately one year long. By the time your company is big enough to sell to Google or go public or whatever, you probably have about 6 layers: the founders and roughly five layers of employees. Each successive layer is larger. There might be two founders, five early employees in layer 2, 25 employees in layer 3, and 200 employees in layer 4. The later layers took less risk.

OK, now here’s how you use that information:

The founders should end up with about 50% of the company, total. Each of the next five layers should end up with about 10% of the company, split equally among everyone in the layer.

Example:

• Two founders start the company. They each take 2500 shares. There are 5000 shares outstanding, so each founder owns half.
• They hire four employees in year one. These four employees each take 250 shares. There are 6000 shares outstanding.
• They hire another 20 employees in year two. Each one takes 50 shares. They get fewer shares because they took less risk, and they get 50 shares because we’re giving each layer 1000 shares to divide up.
• By the time the company has six layers, you have given out 10,000 shares. Each founder ends up owning 25%. Each employee layer owns 10% collectively. The earliest employees who took the most risk own the most shares.

Make sense? You don’t have to follow this exact formula but the basic idea is that you set up “stripes” of seniority, where the top stripe took the most risk and the bottom stripe took the least, and each “stripe” shares an equal number of shares, which magically gives employees more shares for joining early.

A slightly different way to use the stripes is for seniority. Your top stripe is the founders, below that you reserve a whole stripe for the fancy CEO that you recruited who insisted on owning 10%, the stripe below that is for the early employees and also the top managers, etc. However you organize the stripes, it should be simple and clear and easy to understand and not prone to arguments.

Now that we have a fair system set out, there is one important principle. You must have vesting.Preferably 4 or 5 years. Nobody earns their shares until they’ve stayed with the company for a year. A good vesting schedule is 25% in the first year, 2% each additional month. Otherwise your co-founder is going to quit after three weeks and show up, 7 years later, claiming he owns 25% of the company. Itnever makes sense to give anyone equity without vesting. This is an extremely common mistake and it’s terrible when it happens. You have these companies where 3 cofounders have been working day and night for five years, and then you discover there’s some jerk that quit after two weeks and he still thinks he owns 25% of the company for his two weeks of work.

Now, let me clear up some little things that often complicate the picture.

What happens if you raise an investment? The investment can come from anywhere… an angel, a VC, or someone’s dad. Basically, the answer is simple: the investment just dilutes everyone.

Using the example from above… we’re two founders, we gave ourselves 2500 shares each, so we each own 50%, and now we go to a VC and he offers to give us a million dollars in exchange for 1/3rd of the company.

1/3rd of the company is 2500 shares. So you make another 2500 shares and give them to the VC. He owns 1/3rd and you each own 1/3rd. That’s all there is to it.

What happens if not all the early employees need to take a salary? A lot of times you have one founder who has a little bit of money saved up, so she decides to go without a salary for a while, while the other founder, who needs the money, takes a salary. It is tempting just to give the founder who went without pay more shares to make up for it. The trouble is that you can never figure out the right amount of shares to give. This is just going to cause conflicts. Don’t resolve these problems with shares.Instead, just keep a ledger of how much you paid each of the founders, and if someone goes without salary, give them an IOU. Later, when you have money, you’ll pay them back in cash. In a few years when the money comes rolling in, or even after the first VC investment, you can pay back each founder so that each founder has taken exactly the same amount of salary from the company.

Shouldn’t I get more equity because it was my idea? No. Ideas are pretty much worthless. It is not worth the arguments it would cause to pay someone in equity for an idea. If one of you had the idea but you both quit your jobs and started working at the same time, you should both get the same amount of equity. Working on the company is what causes value, not thinking up some crazy invention in the shower.

What if one of the founders doesn’t work full time on the company? Then they’re not a founder. In my book nobody who is not working full time counts as a founder. Anyone who holds on to their day job gets a salary or IOUs, but not equity. If they hang onto that day job until the VC puts in funding and then comes to work for the company full time, they didn’t take nearly as much risk and they deserve to receive equity along with the first layer of employees.

What if someone contributes equipment or other valuable goods (patents, domain names, etc) to the company? Great. Pay for that in cash or IOUs, not shares. Figure out the right price for that computer they brought with them, or their clever word-processing patent, and give them an IOU to be paid off when you’re doing well. Trying to buy things with equity at this early stage just creates inequality, arguments, and unfairness.

How much should the investors own vs. the founders and employees? That depends on market conditions. Realistically, if the investors end up owning more than 50%, the founders are going to feel like sharecroppers and lose motivation, so good investors don’t get greedy that way. If the company can bootstrap without investors, the founders and employees might end up owning 100% of the company. Interestingly enough, the pressure is pretty strong to keep things balanced between investors and founders/employees; an old rule of thumb was that at IPO time (when you had hired all the employees and raised as much money as you were going to raise) the investors would have 50% and the founders/employees would have 50%, but with hot Internet companies in 2011, investors may end up owning a lot less than 50%.

Conclusion

There is no one-size-fits-all solution to this problem, but anything you can do to make it simple, transparent, straightforward, and, above-all, fair, will make your company much more likely to be successful.