Understand and accept that you will make mistakes. The point is to find them early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry. We can, and should, learn, laugh, and move on.

You are not your code. Remember that the entire point of a review is to find problems, and problems will be found. Don’t take it personally when one is uncovered. (Allspaw note – related: see below, number #10, and the points Theo made above.)

No matter how much “karate” you know, someone else will always know more. Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it’s not needed.

Don’t rewrite code without consultation. There’s a fine line between “fixing code” and “rewriting code.” Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer.

Treat people who know less than you with respect, deference, and patience. Non-technical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don’t reinforce this stereotype with anger and impatience.

The only constant in the world is change. Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, rather than some serious inconvenience to be fought.

The only true authority stems from knowledge, not from position. Knowledge engenders authority, and authority engenders respect – so if you want respect in an egoless environment, cultivate knowledge.

Fight for what you believe, but gracefully accept defeat. Understand that sometimes your ideas will be overruled. Even if you are right, don’t take revenge or say “I told you so.” Never make your dearly departed idea a martyr or rallying cry.

Don’t be “the coder in the corner.” Don’t be the person in the dark office emerging only for soda. The coder in the corner is out of sight, out of touch, and out of control. This person has no voice in an open, collaborative environment. Get involved in conversations, and be a participant in your office community.

Critique code instead of people – be kind to the coder, not to the code. As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance, etc.

I like to think I live up to most of those, though I’m somewhat (sometimes very) guilty of #9.

I’ve been working on this book thing, and the bit I wrote about using Laravel with Redactor is quite nice.. if I do say so myself. Here’s a bit…

First, WYSIWYG text editor javascript libraries are pretty hit and miss. But Redactor is brilliant. It looks good, it’s coded well, and it just works. Using it with Laravel is a PHP dev’s dream. So to start, we need to make sure we have a copy of Redactor and have Laravel all set up.

In our routes.php file, we create a route to hold our form with the Redactor field

The image will automatically POST here. So we want to make sure it’s actually an image and is less than 10 megabytes… so we run those validations. If everything validates, we move it to its permanent location, and send out a json response. Redactor expects the json key to be ‘filelink’ and the value to be the path to the image. If everything worked, when you add the image, it will display in your Redactor textarea.

We can check what the code output looks like by creating a route to accept the Redactor data.

Route::post('redactor', function()
{
return dd(Input::all());
});

File uploads through redactor are done pretty much the same way, except with the fileUpload parameter… and the json output should also include a ‘filename’ key.

I did a Laravel bundle for the Postmark API. It’s really just a simple wrapper for the API, and I needed it for a non-Laravel project I worked on, and noticed there wasn’t a bundle already. Probably the one update that would be most useful is getting attachments working. Right now, you have to parse the content and mime-type before attaching… and I should probably update it to just accept the file and do all the parsing in the method. Maybe one day.

Normally when I start a new web project, I just use “http://localhost/project_name_here” as the URL I run, and that’s worked for me. But recently, I started learning and working in Laravel, and one of the…uh… features, is that you have to navigate to the “public” folder. So your URL would be “http://localhost/project_name_here/public”. That was fine while I was learning, but I’m about to start a new project, and I don’t want that “public” in there.

I first thought about modifying the htaccess file and putting the “public/index.php” file into the root and changing the paths, but I decided to go the Apache VirtualHost route. Of course, since I’m using WAMP, most of the suggestions about VirtualHosts, like from Code Happy, don’t apply… and searching for WAMP VirtualHost shows as many solutions as there are results. So here’s what I did…

1) Go into your WAMP Apache config files. My wamp is located a c:/wamp, so the path to my config files is C:/wamp/bin/apache/Apache2.2.17/conf

a) open httpd.conf in a text editor
b) located the line

#Include conf/extra/httpd-vhosts.conf

And remove the first “#”
c) go into the extra folder, and edit the httpd-vhosts.conf file. Here’s what I added..

A little over a month ago, I started toying around with other PHP Frameworks besides my first love, CodeIgniter. I was familiar with Kohana, because of its CI ties, and I tried out Yii and even micro-frameworks like Slim. Then, somewhere in my Twitter stream, I came across a tutorial for Laravel from a site by Dayle Rees. There was also talk of an impending book release based on those tutorials, and when it was released, I happily bought a copy of Code Happy. And while it could just be effective mind-control marketing on their part, I really did find it fun to learn and code. So the following are some tutorials that helped me along the way to learning about Laravel…

If you want to get up-and-running quickly, even without previous framework experience, I can’t recommend this book enough. The minimum price is $5, but if you don’t give at least $10, you’re a big, stupid jerk. Seriously. There’s already been an update to Laravel, and he updated the book almost immediately after… and once you buy it, you get the updates for free. Beyond the fact that this is an immensely helpful book, people need to support this publishing model.

You can also find most of the material on his blog, if you want to see what you’re getting.

He caused a bit of an “uproar” over his Codeigniter is dead post, but his Laravel tutorials are top-notch. And screencasts to boot… which are always cool. The controllers and routes tutorials are great for beginners, and get you started making sites pretty quickly. I just watched his Form Model screencast, and I’m eager to try out that bundle.

There aren’t a whole lot of these, but they serve as a great introduction to the framework. If you want to get acquainted with the Eloquent ORM, there are some good videos… and I found the overview of the Blade templating system to be informative.

This is a very young framework, but the documentation is very well done and extensive. One of the reason I love PHP and Codeigniter is because they are both well documented, and if I have a question about a method, or the order of arguments for a function, I know exactly where to go. Laravel has taken this notion to heart right from the beginning. And if you can’t find your answer there, the forums are a great place to ask your question. In fact, the guys that did these tutorials are frequently the ones to answer questions… so you’d be getting expert advice.

So eventhough Laravel is probably one of the youngest PHP frameworks, it seems to be gaining a lot of steam very quickly. People love it even if they don’t plan on using it. So hopefully, this list will only expand as more people jump on board.

In part 1, I got Ubuntu installed and was able to connect from my Windows laptop. Now I need to get Apache, MySQL, and PHP installed.

First, Apache. The command to install is simple: sudo apt-get install apache2 … and a few minutes later, Apache is up and running. I put the ip address into my browser, and i got “It Works!”. Sweet.

To get PHP working, I followed this installation guide. The guide is more for if you are USING the machine you’re installing to, but it works over SSH. The one extra thing I did was get into the /var/www directory… then type sudo nano test.php . In the file I put in <?php phpinfo(); and then Ctrl-O to save it. Then in the browser, went to http://192.168.1.6/test.php and I got the PHP configuration page. It worked again!

I followed the install guide for MySQL, and in a couple of minutes it was done. I kept the main user as “root” with no password, then the command “mysql -u root” got me connected with no problem. Then there’s this handy page with lots of useful commands.

So I’m all set up. Now, I’m wondering what to do next. How can I transfer local files to the dev machine? I’ve read about installing samba and then map a drive… or use git, and push it to the dev machine… or even something like Phing, which I’d need a crash course in. That’s next…

The one thing that’s difficult to tell from a programmer’s résumé is “Can they actually code?” Sure, they may have had some coding jobs in the past, or have some schooling in programming, but that doesn’t tell you much about their actual skill. Or maybe they DON’T have the schooling or work experience, but have done tons of personal projects or worked in open source projects… a résumé might miss that talented coder. One of the things that I see a lot of tech people looking for recently is a Github account, and examples of coding or helping with open source projects, which is great.

As I thought about putting together a résumé, I wondered how can I demonstrate understanding of modern PHP concepts, without the hiring person needing to jump through a lot of hoops, or visit a bunch of sites. So I created a résumé in code, and got some useful tips from the Forrst community as well.

The goal was to make a resume that could be readable to a non-programmer. And I think if you look at it, you should be able to follow along:

$myResume->myName = “Terry Matula”;

$myResume->myEmail = “terrymatula-at-gmail-dot-com”;

$myResume->myPhone = “281-656-1474”;

// Places I’ve worked

$workExperience = array();

etc…

Even if you knew nothing about coding, that should make sense. And the great thing is, if you copy the file to a server and run it, it actually makes a somewhat nice looking résumé page.

I had experimented with Datamapper, and it was great. But there was complex join statement I needed that DM didn’t support… so I had to just write out the SQL like normal. I then realized it’s just as easy to use CI’s Active Record or regular query command and create your own methods. Plus, it keeps things pretty speedy.

2) You DO need a base Model

I’ve only just recently started using Jamie Rumbelow’s MY_Model and it’s changed everything. Previously, when I wanting to get a single record from a table, I was writing $this->db->from('table')->where('id',$id)->limit(1)->get()->row(); for every single table. Now, that’s already included for every Model I make.

3) It’s helpful to look at the core code

For example, I was curious how the Active Record was implemented, so I opened up DB_active_rec.php. I know some people prefer to use “->get()” by adding in the table name and limit as parameters, and I wondering if there was difference in how it’s handled. Interestingly, it runs the exact same “from()” method, just as if you had “->from()” in the query.

And while this is a micro-optimization, if you want to return a single result and you’re sure it’s the first result… use “->limit(1)”. The “row()” method will work with multiple rows returned, so there’s logic built in to just return the first row. Adding “->limit(1)” will help skip all that.

4) The url helper really needs to be auto-loaded by default

In my autoload file, I always load the database and sessions libraries and the url helper. I can’t remember a project where those didn’t get used. I’ll occasionally autoload the form helper as well, but that’s a project-by-project call.

But the url helper… I honestly can’t see how anyone would ever NOT use that in every project. “site_url()” and “redirect()” just seem like no-brainers.

5) Object-Oriented programming and MVC

Prior to learning Codeigniter, I was experience in Drupal and WordPress, and a bit of Joomla, but working with them isn’t strict OO. The custom stuff I programmed was really procedural or functional, based on the fact that I learned programming using PHP 4 and classic ASP/ vbscript. While I read about and tried using Classes and methods, I just didn’t get it. With CI, I had the ‘flipped switch’ moment, where Objects and Classes made total sense.

Now, I’m onto learning as much as I can about OO in PHP 5.3, including namespaces and inheritance… which aren’t yet built into CI

I put my email address into a lot of forms, especially because I like to check out new sites and services, and I’m always hoping for the “beta” invite. Inevitably, this means I also get added (without my knowing) to a lot of email lists. At the bottom of most emails is usually (if they’re following the law) a link to “unsubscribe”. I’ve noticed some companies do unsubscribes right, and others… not so much. So here are my rules that you should always follow for YOUR email list:

1) The best unsubscribe link takes you to a page that says “You’ve been removed from our list”… and that’s it. Simple, effective, and I won’t hate you or your company afterwards.

2) The second best way (if you really think your email recipients are so stupid they may click it unintentionally) is to have a page with two buttons. One saying “Unsubscribe” and another saying “Oops! I made a mistake! I don’t know how links works! Derp” or something.

3) NEVER ask for my email address to unsubscribe. You sent me the freaking email, you should KNOW my address. Also, I often use the “plus trick” for my gmail, and asking me to track down exactly what email address I used for your stupid, spammy site will just fill me rage and hatred for you and your babies.

4) NEVER send an “Unsubscribe Confirmation” email. Seriously? Are you that stupid? I just said “Don’t send me any more emails” and you’re going to do the exact opposite? How are you able to feed and clothe yourself?

5) Do NOT ask me to sign in and “change my notification preferences”. More than likely, I already forgot the password for your lame company that TechCrunch will never cover, and I’ll just have to do a “forgot password” thingy… meaning I must both find what email address I used AND get another email from you. Fail. Fail. Hatred. Fail.