Today, after seeing a tweet by Jeffery Zeldman that was retweeted by Andy Budd, I came across a new favorite website: Dark Patterns.

These patterns are not to be confused with Anti-Patterns. Anti-Patterns are commonly used techniques that are in-effective or counter-productive. They are consideres mistakes with unintentional consequences or pitfalls. Dark Patterns, however, are things web designers & developers do on purpose. From the home page of Dark Patterns website:

Normally when you think of “bad design”, you think of laziness or mistakes. These are known as design anti-patterns. Dark Patterns are different – they are not mistakes, they are carefully crafted with a solid understanding of human psychology, and they do not have the user’s interests in mind.

The website then names several of these “Dark Patterns”: Friend Spam, Privacy Zuckering, Misdirection, Bait and Switch, and many others.

I recommend checking out their website, and then self evaluating your own projects asking these questions:

• Do I use these Dark Patterns?
• Do any projects I work on use these Dark Patterns?
• If so, how can I fix them?

The Dark Patterns website has a 20 minute video which is a recorded presentation an event. What I best like about it is it shows a few examples of Dark Patterns, and then walks through the logic of avoiding them. I recommend giving it a view:

Related posts:

1. Five common PHP design patterns that aren’t used enough
2. Utah PHP Users Group
3. DRM vs. Users – The Good and The Bad

Today some memories came from when I first started with web development. So before I forget anymore of the details, I thought I would share my unique way I became a web developer. I never went to school to learn Computer Science or Information Systems. I’ve had a total of 2 programming classes, which were my in sophomore and junior years of High School, one of which we lovingly nicknamed Warcraft 101, because we would spend the entire time getting out butts kicked in Warcraft 2 by my classmate Daren (We all got A’s, we had just finished the entire coursework in 2 and a half weeks).

The reason I share this is perhaps others who hope to become a web developer can learn some of the valuable lessons I picked up along the way. That, and that my close programming friends and colleagues can get a kick out of my humble roots.

Heritage

How I ended up in Technology to begin with is probably because part of it is in my blood. My Father, Kevin Carmony, has been the owner of several technology businesses. So I was exposed frequently to computers and other technologies my whole life. I remember some time when I was about five or six, in the late 1980s, playing against my younger brother on a multiplayer ASCII LAN game at the old Streamlined Information Systems office. It was wandering around a 2D maze hunting these 8-bit monsters, and each other, and it was amazing fun.

I also had access to a lot of expensive software that were hand-me-downs. One of them I remember is Photoshop 3 and 4, spending hours trying to design websites with it. To give you an idea how old that is, the current version is CS5 (aka version 12). The first program I really used to make a website was (and get ready to gasp) Microsoft FrontPage in 1997. There were also a couple of website books laying around that I would read, or at least try to.

On the other side of the equation was my mother, while herself wasn’t extremely technical, encouraged and “sponsored” my learning when I was young. By sponsoring I mean she many times bought computers, digital piano keyboards, DSL (we were some of the very first people to have “high” speed internet in our town), and paid for many other expenses. I remember a several hundred dollar long distance bill because I would call the “Provo” dial-up connection instead of the broken “Ogden” phone number. I even once ordered a “temporary” AOL dial-up account, with her credit card and without permission, because our ISP was down, and I needed to check my website. I forgot to cancel it afterward, and it racked up a few months of fees before my mother realized what had happened. She never yelled or mad over these “expenses”, that I realize now as an adult, were not cheap. She just told me in the future what to do to avoid causing them again.

She was also very patient with a son whose grades weren’t the best, and who would rather work on a website than do his homework. I know if she would have came down hard on me, my GPA would probably be higher (its wasn’t bad, just not great), but I wouldn’t have learned what I did, nor make the connections that eventually fast tracked my career. I owe her a great deal (I love you mom!)

Humble Beginnings

I first learned about websites, and how I could make them, while sitting in my 7th Grade Band Class. My fellow clarinet player Kenny Cottrell explained to me in between songs about HTML, Notepad, and how I could learn to make my own website. So I set off to learn HTML. In my excitement, I found an online book on HTML, and printed the entire 400 page book on my mother’s home printer. Single page, of course, because I couldn’t figure out how to easily do double page, and it was on her expensive laser printer (this was 1997) with expensive cartridges.

My very first website was hosted on one of my father’s web servers, and using FrontPage, I made a website about a game called The Realm, one of the very first graphical Massive Multiplayer Online games (MMO, think World of Warcraft). It was bad, really bad. I can’t find any pictures or old files from it, but you can take my word for it. When spending weekends at my Grandma’s house with my Dad, I would spend hours designing and writing websites, or at least try to. They were all bad, but I learned a lot by trying over and over again. I would design a site, look a a professional site, and try to see why mine stunk while the professional ones were so much nicer. I remember looking at Amazon‘s rounded corner tabs for hours trying to get mine to look just as nice.

I then got my first domain, RPGLegacy.com, in 1998 and started a website with game reviews and walkthroughs for PlayStation RPG games. I remember writing reviews and information for games like Final Fantasy VII, Suikoden I & II, and even more obscure (and terrible) titles like The Granstream Saga. I started to get perhaps 100 visitors a month, and I thought that was great. I even got emails from people asking me for help. One subject in particular was in Breath of Fire 3 dozens had emailed me about getting stuck in a castle. I myself had gotten stuck in the same place for hours, and posted an in-depth solution for finding Honey the Robot in the castle. For being a 15 year old kid in junior high, it was a lot of fun, and I learned a lot. I had moved to Dreamweaver for making the website, and the designs weren’t half bad. However, I don’t have a screenshot of how the old site used to look.

Counter-Hack

I was 16 and I in high school. My classmate Daren (the same who whooped me at Warcraft 2) introduced me to a game called Counter-Strike. It was a First Person Shooter, and it was a lot of fun. However, at the same time, there were a lot of these “cheats” and “hacks” programs that were coming out. My friends and I would be accused of “cheating” and “hacking” when in reality we weren’t. Also, some of the claims on how we were cheating were rather absurd. So I started to investigate the truth and fiction behind these programs. I learned a lot, and thought I would share that knowledge, so I started Counter-Hack (http://www.counter-hack.net) in the summer of 2001.

Little did I know how extremely popular this website would become. Within a week or two I had a website wtih decent content up using Dreamweaver. This was 100% HTML based, no CSS, trying to use Dreamweaver’s Template system. What I would have given for some PHP or even WordPress. While with RPGLegacy, I had maybe a max of 5,000 visitors over it’s entire lifespan, within a month I had 30,000 visitors to Counter-Hack. Soon I was getting thousands of visitors per day. About the same time I met Anthony Ouwehand (nicknamed H3X), who had ran another popular website about video game hacks. He graciously helped me with his PHP/MySQL skills. He designed, and developed, the Counter-Hack website that was launched in 2002 and ran until 2008 when everyone involved with the project just were too busy, and the site had ran it’s course and purpose. Two years of that time the project ran with the rest of the volunteers while I served an LDS Mission in Torreon Mexico.

During the years with Counter-Hack, a few highlights were interviews with Wired for news stories, working with Valve Software to help recover the HL2 Leak, and an interview and article with Rolling Stone Magazine. During it’s height, Counter-Hack was covering dozens of games with hundreds of thousands of visitors a month. During it’s later years, Counter-Hack implemented a Wiki system for much of it’s content, something that was pretty new at the time. All and all, it was a great experience with dozens of volunteers and great memories. For a hobby during High School and the year after graduating, I couldn’t have asked for a better experience. I learned a lot before even starting college.

Developing Out of Necessity for CEVO

The reason why for the background story is for two reasons: I had started practicing web design and development from a very early time, and I gained a unique background and knowledge with my work with Counter-Hack. So in March 2005, being home only a few weeks from Mexico and still with a heavy mexican accent, I was approached to work with a company called CEVO. It was an online video game league that was emerging, and their first game was Counter-Strike. They needed someone to help consult with preventing cheating and “hacking” in their matches, and I was a perfect fit. So I joined as a consultant, and quickly became the Operations Director within a few months. CEVO also had brought on Eric Ping to be the CTO, and the company started to grow.

One of the challenges CEVO faced was it was a completely distributed team. Charlie Plitt, the owner, lived in Baltimore, MD, Eric lived in Ephrata, WS, and I lived in Ogden, UT. We had staff and volunteers that literally lived in all 50 states except Hawaii and Alaska, as well as some across Canada. Our customers also lived all over North America, and we relied on the Website, Email, and VoIP to run the entire company. It was insane and awesome at the same time. This put a ton of demand on Eric, our only developer for the website, to get new features implemented quickly. During the first two years, we had re-designed the website a total of 6 times before finally settling down on the current design, which is being redesigned now as well. Eric couldn’t handle it all, and since we didn’t have the funds to hire another developer, I thought since I knew something about web design and programming, I could help out.

Eric took me under his wing and basically mentored me along as I started to take on project after project. I had become familiar with PHP and MySQL when I was tinkering with Counter-Hack’s code, but now I was really learning. I was also learning extremely quickly because I had no other option. It wasn’t like working at another company where I had a team of Senior Developers that could bail me out. Eric worked such late hours that normally if I was awake, he was asleep, and we meet for a few hours in the afternoon and evenings. But if I had a bug, or a problem, there was only one person who could solve the problems: myself. Working on a team of two developers for a start-up company is extremely demanding, and I was constantly looking for ways to work more efficiently. It was the only way to meet CEVO’s growing demands, by learning how to be a quicker and better developer. So while I had a day-job of doing Tech Support for a local company, I spent every other free moment working for CEVO. As CEVO grew, we ran into scaling problems and performance problems, things a normal “Jr. Developer” wouldn’t have hands-on experience dealing with.

Eventually, I had learned so much working for CEVO, that I was able to quit my day-job doing tech support, and did contract work on the side. I helped launch some e-commerce websites, some basic business websites, and spent the rest of the time working on CEVO. I had started to go back to school for my Business Administration degree at WSU, and I was pretty much busy non-stop. But it was a lot of fun, and allowed me a lot of freedom not having a normal 9 to 5 job.

Ambient Partners, LLC

In 2006, I had the most amazing thing happen to me: I met my wife. We had dated for almost a year and we decided to get married. So by the end of 2006, I had a serious realization: I needed a steady income. While contract work paid really well, I could go a month or two without a check from clients. When living at home with relatively no expenses with the exception of my car, I could get away with this. But health insurance, rent, groceries, etc. I couldn’t live that way. So I decided to find a full-time programming job. Fortunately, the company I had worked tech support at had split with their California office and changed names. They were a company primarily doing software for DVD Rental Kiosks, and needed a Web Developer to do work on their web technologies. So by January 1st, 2007, I became a full-time employee for Ambient Partners. Our development team consisted of myself, a Senior Developer, and the CTO. As I look back at what the three of us accomplished as a development team, it amazes me.

When I joined, our main client had about 100 kiosks in the field. After doing the company website, I was given a very big project: RBO, Rent-Buy-Online. We wanted to provide clients with “white-label” solution to allow people to reserve and buy DVDs on a website, and then go pick them up at a Kiosk. There were two parts to this solution. The website itself, and the web services to supply the website with data. I had never written web services before, so I had a lot to learn very quickly. Also, it was to be written completely in ASP .NET, a framework, and C#, a language, I had never worked with before. So I started to learn how to build this project in .NET. It was very difficult on multiple fronts, but on in particular that I had underestimated was going from a loosely-typed language (PHP) to a strongly-typed language (C# .NET). So I tried several different methods, started a few different projects, and after a three months I got an email from my boss. It was short and sweet: “Justin, money is tight and we can’t afford to keep you on staff if you’re unable to make real progress on RBO. Either we need to see some real progress very soon, or staffing changes will be made.”

I learned very quickly that spinning your wheels trying to do something perfect, but never getting done, is an excellent way to stay unemployeed. I immediately shifted gears after the thought of explaining to my new wife that I had lost my job. Fortunately, after the fear of doing something wrong was overcome by my fear of not finishing anything, I completed RBO to version 1 in record time. I had made some ugly coding decision that we refractored out later, or scratched completely, but it was a working prototype. My boss was happy, and I was happy and still employed. While the front website has been redone for Blockbuster Express, it is powered by the same web services I built in 2007.

After building RBO, I was tasked with building a reporting & support suite that would manage millions of transactions. This second project went much smoother, and I put a lot of effort into it. I knew the people making the decision whether or not to buy our multi-million dollar software suite would be personally using this piece of our solution, so I wanted it to make them really smile. I was told after the demo of our new software suite, the executives all mentioned they were looking forward to using their “executive reporting tool.” Several months later, after successfully building some pretty slick software with the rest of the team (of which other things were even cooler then what I made, like Chris’s auto-updater system), Ambient Partners was purchased by NRC.

Dating DNA

By 2008 when the NCR deal was underway, I had a choice. I could stay, take a very nice raise, and work for a very large corporation. But, deep down inside, I had a bad feeling about working for NCR. As a small team, we were very effective and there was almost zero political or bureaucratic non-sense in Ambient. As for NCR, I would go from being a developer in a company of three developers to a company of hundreds, if not thousands, of developers. I was also tired of working in .NET and Web Services, as I was moving away from what I loved to do: building cool websites with cool technology.

My father at the same time was working on his new business: Dating DNA. They had a web developer in San Diego, but he was expensive because living in San Diego is expensive. So Kevin asked me if I would be interested in working for Dating DNA. We tested the waters by having myself build a Web-based iPhone App for Dating DNA (the App SDK hadn’t been released yet.) It worked really well, so I turned down the offer to become an NCR employee, and returned to my roots as a developer: working from home working with code I love.

Through 2008 and 2009 I worked as a full-time developer for Dating DNA. I took over all responsibilities for all their technology. In those two years, we did a lot. I’ll have to write a new blog post to completely cover everything we did that was awesome, but here were a few highlights: Built a real-time score generation system that could calculate hundreds of scores per second. Built the iPhone’s first Dating App, and to this day is a top ranking App in the charts and highest rated dating app. We scaled from 3,000 users to hundreds of thousands of users. We built a handful of new iPhone Apps, the main one being Clipish. We built custom chat rooms using Ajax and Comet, and a bunch of other stuff.

Alienware & CEVO

All this time, I was still doing work in the evenings with CEVO. In 2009, we were approached with the opportunity to do something we hadn’t done before in CEVO. Dell’s brand Alienware wanted us to make them a website like CEVO’s, only completely branded for Alienware. We built, from the ground up, and custom solution for Dell and Alienware, and Alienware Arena was born. This was a great project to work on, and we were able to get it done on an extremely tight timeline and a strict budget. I did 100% of all the graphical design, following Alienware’s look and feel, and I’m very proud with the result. It was built by myself, Eric Ping, and our new talented developer Mike Stevens. While I can’t say how many members Alienware Arena now has, it is a lot. Building such a successful website for a large company like Dell doesn’t come around very often. Each year Dell has us add more and more features to it, and it has been a great project for CEVO.

Utah Open Source

One thing that happened in November 2008 that I would consider one of the crucial events that “fast-tracked” my education as a web developer was being introduced to the local Open Source groups in Utah. I spoke at the Utah PHP Usergroup and was introduced to the Utah Open Source Foundation. Through these groups, I met dozens, and eventually hundreds, of talented, passionate people. While through CEVO I fast-tracked my web design and PHP development, through the Open Source groups I broadened my knowledge of so many more technologies. I learned about nginx, nagios, redis, memcached, php apc, linux server administration, and Git just to name a few off the top of my head. What is great is not only did I learn about these things, but I met people who know a lot about them. So when I ran into problems, I already knew a solution that could work, and knew people I could ask questions too. That, and I’ve made a lot of great friends through the different meetings, lunches, and conferences. I’ve picked up some contract work through my connections with these groups, and overall they have been extremely beneficial and great.

Chief Technology Officer

All of these different things played a part in me having the job I have today, CTO of Dating DNA. I’ve written already about my new responsibilities as our new CTO, and what it means for the company. These few short months as CTO we’ve made a lot of changes to handle even more scaling (especially with holiday surges and such). We’re in the process of improving our already fast score generation system, and moving our user photos to a more scalable solution in the near future. We’re evaluating our usability and such for our website, and seeing if a redesign on certain areas would be beneficial. There is a lot of work to be done, but I truly enjoy it.

Advice & Lessons Learned

After reading and thinking about the different things I’ve experienced and gone through to get me to this point, I’ve had a few thoughts that I think can help anyone in our field, and other fields of work:

• Surround yourself by people who help each other learn – Looking back, all of the people who have really helped me along with my career and education (not just schooling) have been people who help everyone learn. They each others things, and then learn from others. They harbor a culture of continual learning, and being in the tech industry which is always changing, this is critical.
• Always be learning something new, always – Trust me, there is always something to learn in this industry. Even if you’re learning something that isn’t directly involved, you never know what it might lead to. My work with Counter-Hack lead me to CEVO, which in turn lead to an accelerated web development “course” of “holy crap, we need to get this done and working or we crash and burn.” Even to this day, a lot of the things I learned about how hacks work I apply in other areas of computer science.
• Don’t let formal education be your only source of knowledge – Those that know me know I can be a little “harsh” when talking about formal educational institutions. Especially my frustrations with certain types of developers that are produced from these institutions. But the bottom line is this: they can be a great source of knowledge, and you can learn a lot from them. However, if you don’t learn additional information outside of the classroom, you are going to be sorely disappointed at how much you know when you graduate. Fundamentals are crucial, but practical application is just as important.
• Apply and build something important to you – There isn’t a better teacher than experience, and getting is as soon as possible, and as frequent as possible, will help a lot. I’ve spent more years unprofessional doing my job than professionally (at least for another year or two). Working on something meaningful to you, not just going through the motions of tutorials, really teach someone what it is like to do this kind of work.
• Networking and getting to know people is crucial – There is such an important emphasis on skill in the technical world, that knowing people and their actual abilities is vital. Also being know for your set of knowledge is important. That way when you want to learn something new, you know who to seek out. Before becoming Dating DNA’s CTO, and the rumor went out I was considering a new job, I had a lot of people contact me to see if I was interested in certain positions. There is no down side to being a “social” developer. Just because this isn’t “Marketing” doesn’t mean social networking isn’t important. I personally don’t like the term “networking” since it makes it seem like a chore. Make lots of friends in the programming groups and circles in your area and community, and it will be beneficial.
• Love what you do – If you don’t love what you do, then there is a good chance you will not go far in this industry. It doesn’t mean this is the only thing you do. Other hobbies and activities are important. But if you dread going to work, and do your work, every day, then it’s time to find something else.

This went a lot later in the evening than I thought, so I hope my thoughts are coherent, and if nothing else, entertaining. Its been a great deal of fun since those first days with Photoshop 3 trying to design something that didn’t look terrible. I look forward to the next few decades to see where web technology takes us.

Related posts:

1. So You Want To Be A Web Developer?
2. Web Development 10-Years Ago & Now
3. Being a Productive Developer

Unfortunately, I haven’t been able to attend a conference where he is speaking at. However, thanks to the wonders of the internet, there are several videos and slides available from previous presentations. I highly recommend them for any web designer or developer, because we all deal with usability in one form or another. I’ve gone ahead and gathered a handful of these videos and slides into one article so I can easy reference them for others to watch. You’ll notice a lot of the themes and ideas in these videos will overlap, but each one has some very good content and advice.

Designing the User Experience Curve

This is the first video I watched of one of his presentations, and it has stuck with me for the last year or two. Warning, after watching this video you will no longer look at interacting with others the same, whether on the web or just day to day encounters. You’ll know what I mean after watching this video.

Slides

Video

Andy Budd – FOWD London 2008 from Future of Web Design on Vimeo.

Persuasive Design: Encouraging Your Users To Do What You Want Them To!

This is a more recent presentation, and while I couldn’t find a full start to finish video, I have pieced together a collection of videos that covers most of it. There are quite a few “aha!” moments that make you realize different things, and rather fun to listen to.

Slides

Videos

Seductive Design

This one is very similar to the first video, but there are some differences once you delve into more of the content. There are some very good ideas in here. Now, this isn’t so much about seductive marketing as it is creating appealing designs.

Slides

Video

Andy Budd – Seductive Design from Build on Vimeo.

Want more?

There are a few more slides of his presentations on slideshare. I would also recommend subscribing to his blog. Hopefully you enjoyed these videos and much as I did.

Related posts:

1. Web Design & The Cookie Jar: When Dealing with Clients
2. New Blog Design
3. PHP Design – Biggest Database Oversights

Dear Google Apps admin,​

In order to continue to improve our products and deliver more sophisticated features and performance, we are harnessing some of the latest improvements in web browser technology. This includes faster JavaScript processing and new standards like HTML5. As a result, over the course of 2010, we will be phasing out support for Microsoft Internet Explorer 6.0 ​as well as other older browsers that are not supported by their own manufacturers.

We plan to begin phasing out support of these older browsers on the Google Docs suite and the Google Sites editor on March 1, 2010. After that point, certain functionality within these applications may have higher latency and may not work correctly in these older browsers. Later in 2010, we will start to phase out support for these browsers for Google Mail and Google Calendar.

Google Apps will continue to support Internet Explorer 7.0 and above, Firefox 3.0 and above, Google Chrome 4.0 and above, and Safari 3.0 and above.

Starting this week, users on these older browsers will see a message in Google Docs and the Google Sites editor explaining this change and asking them to upgrade their browser. We will also alert you again closer to March 1 to remind you of this change.

In 2009, the Google Apps team delivered more than 100 improvements to enhance your product experience. We are aiming to beat that in 2010 and continue to deliver the best and most innovative collaboration products for businesses.

Thank you for your continued support!

Sincerely,

The Google Apps team

For all Web Developers around the world, we should all be rejoicing! Having a large internet giant telling its consumers to “drop IE 6″ and other older browsers will make all our lives easy. I remember while working on a very large site, we used PNG images sparely for some background images. The deadline was extremely tight, but we were (barely) on schedule. Out of the blue I get an email forwarded to me from the marketing director for the client, and it went something like this:

Why are all the backgrounds looking nothing like the mock? Its all a funny blue.

Of course, the Marketing Director had IE 6. Whats worse, is that he was working for a very large computer technology business. We had to drop everything and apply ugly IE 6 hacks to enable PNG support. At the time, I tried explaining that the browser he was using was released while I was still in highschool, but he didn’t understand. Hopefully now the big internet giants will start telling people “Get off IE 6.” Once people adapt better browsers, the more we can do with the web.

Related posts:

1. Why Google Chrome is Good for FireFox
2. Is Google following Microsoft’s footsteps?
3. Google Wave Jargon

I’ve gone back and looked at this year of 2009, and the things I’ve blogged about, and I thought I’d give a little recap.

My CSS Conversion

At the beginning of the year I realized I had 100% percent to using CSS. I’m still a little in awe that being such a table junkie I finally did it. There were a few key things that I did to help me learn all the difficult things with CSS. I hope I can help some poor web developer out there understand their CSS a little better.

A Year of PHP IDEs

I really invested some time in trying out and experimenting with several PHP Integrated Development Environments (IDEs). I had been using Zend Studio for several years, however more and more I found myself frustrated with it’s quirks. However, I haven’t had time yet to blog about the new IDE I am using, NetBeans. I’ve made the switch from Zend Studio to NetBeans, and while I’m not completely sold, I’m still giving it some time. Maybe over christmas break I’ll blog some about it.

Interesting Challenges w/ MySQL

While I haven’t blogged about most of them, I have had some interesting challenges w/ MySQL over the last year. One was converting 40 Million rows from a MyISAM engine to an InnoDB Engine. I’ve been having some serious heart-to-heart conversations with MySQL (metaphorically of course) on how I’m going to scale it to millions and billions of rows. I think I’ve mapped out in my head how we’re going to handle it for Dating DNA. That will be one challenge I’ll be addressing in 2010.

New Blog Design

This year I got around to re-designing my blog using the Carrington Theme as a base. I kinda like it, but it still could use a little more polish. One day I’ll find time to give it that extra polish.

Memcached

This year I really got into the theory on how to design an application with Memcached. I’ve decreased the load on several websites by using it, and wrote an in-depth article on the theory of caching, and how to implement it effectively. I’ve been amazed at how well it works, and that I hadn’t used it before.

A Year of Presentations

I’ve given two presentations this year, my Memcached presentation at UPHPU, and my “Real Life Scaling” presentation at the Utah Open Source Conference. I got great feedback from both presentations, and I look forward to what I’ll present on this upcoming year. I’m thinking about putting together a presentation called “Being a Web Ninja with jQuery,” and showing of the dozen of awesome applications I’ve built using jQuery.

Utah Open Source Conference 2009

This year I helped organize and throw together the Utah Open Source Conference. I was made the Sponsorship Manager, and it was interesting trying to talk to companies in a recession about donating to a non-profit conference. I haven’t had a chance to blog about different techniques on how to professional ask for money for something like this, but hopefully in 2010 I’ll be able to share some insights.

Things I Didn’t Blog About

There were a lot of things I didn’t get around to blogging about this year. I’ll quickly touch on them here, and hopefully in 2010 I’ll be able to blog about them more.

Web Services – I’ve done a LOT of web service work. Web services provide a unique challenge, since many times its hard to debug them. At my old job, one of the biggest challenges is we really couldn’t debug our web services until all of the other pieces of the puzzle were done. Then we spent long hours with trial and error, debugging via dumping logs. I’ve learned a lot of tricks with PHP and web services. Hopefully I’ll be blog more about those soon.

Performance Tuning LAMP – I’ve had to do a lot of tuning to keep the Dating DNA website afloat. Because of the awesomeness of our iPhone apps, we’ve had a lot of load on our web servers. There are a lot of things you can do to get the LAMP stack to run well.

Alienware Arena – Here was a fun little project I was able to crank out for probably the largest client I’ve done work for: Dell. We made them a website for their Alienware brand called “Alienware Arena.”

There were a lot of challenges to this website, mainly timeline and budget. But we were able to walk away happy with our work, and the Dell / Alienware team were really happy. It was interesting going through and trying to copy / mimic the look and feel of the Alienware website. I’m really proud of what we made.

Never Ending iPhone App Store Saga – Anyone who knows me has heard of the bloody wars that my current employer has had with Apple, their iPhone, and the App Store. The ridiculous approval process, the extremely long wait periods, and Apple’s OCD when it comes to their phone. I won’t say much anything else on the topic, but boy it has been frustrating.

What to Expect with 2010

Boy, 2010 will be interesting. What to expect? I’ll be doing some pretty sick programming in jQuery, as I’ll be adding integrating chat to the Dating DNA website. What else? A lot more when it comes to integrating websites into other social network platforms.

From a business platform, 2010 will be a lot of work spent on taking some great ideas and trying to monetize them. While working on awesome stuff is great, its important to pay the bills with them. I will have an entire year to sign up Sponsors for the 2010 UTOS Conference instead of 2 short months.

Hopefully I’ll get in a better habit of documenting my discoveries and solutions here in my blog. Sharing information is the best way to help everyone out.

I hope everyone has a happy holiday and good luck in the new year! 2010, here we come!

Related posts:

1. Speaking: Utah Open Source Conference 2009
2. So You Want To Be A Web Developer?
3. Presentation: Real Life Scaling

This is not a criticism of clients, however. There is so little information that clearly defines their role. Sure, there is no shortage of material on usability, accessibility, online marketing and copywriting, but who has the time to read all of it?

…

One of the biggest problems in most web projects is that the client starts making the decisions that are best left to the web designer. Not only does this lead to bad decisions, but also inevitably leaves the web designer feeling undervalued and frustrated.

This problem can manifest in a variety of ways, however ultimately it comes down to a single issue – the client is trying to find solutions to their problems instead of relying on the web designer.

…

The most obvious occurs at the design stage. After seeing your design the client comes back with comments such as ‘make the logo bigger’. This is their solution to a problem that they have with the prominence of the branding. If they had expressed the problem instead of the solution, it would have enabled you to suggest alternate approaches. Instead of making the logo bigger, you could have possibly added more whitespace or changed its position.

I highly recommend the read. It also looks like the blog post author wrote a book called “The Website Owner’s Manual“. Maybe I’ll have to get a copy and see if it is any good.

Related posts:

1. Software Development With Clients In Mind
2. Great PHP Article: Leadership in Software Development
3. Web Design & The Cookie Jar: When Dealing with Clients

Today’s trick is using a better toggle method than the standard toggle function. Don’t get me wrong, it works great, but only if it is the only method for “toggling” the given element. Traditionally you pass is several functions, typically two. Function #1 that executes the first time that the event is fired, and a second function that fires the second time you click on it.

The problem arrises if you want to have more control over who, what, and where executes the toggles. Lets say you have a hidden div that is rather large, and a link above it that says “More Information.” You click the link, it fires Function A and it slides down the div. Since it is so big, at the bottom you of the div you put a link that says “Close.” The user clicks this link, and it hides the div again. The problem is the toggle function isn’t away that another part of the website hid the div. So if the user clicks “More Information”, it will still call Function #2, which will re-display the hiding annimation.

How do we solve this problem? Instead of using the toggle function, we write our own like so:

<h2>Better Toggle Method</h2>
<div id="new">
  <a href="#" class="toggle">Toggle More</a>
  <div class="more" style="display:none;">
    <p>More Text Here</p>
    <p><a href="#" class="close">Close</a></p>
  </div>
</div>
<script type="text/javascript">
  // Assign Events on Page Ready
  $(document).ready(function(){
    // Create Toggle Function
    $('#new .toggle').click(function(){
      // If display is none, that means it is hidden
      if($('#new .more').css('display') == 'none')
      {
        $('#new .more').slideDown();
      }
      // Second Click
      else
      {
        $('#new .more').slideUp();
      }
    });

    // Create Close Function
    $('#new .close').click(function(){
      $('#new .more').slideUp();
    });
  });
</script>

If you want to see an example of the old method, as well as the new method in action, you can see them here. Hopefully this can help you out.

Related posts:

1. Empowering JavaScript Through jQuery
2. ASP .NET 2.0, GridViews, HyperLinkField, and JavaScript
3. PHP Singletons, Sub-Classing, and HAS-A Relationships

This last week I’ve been talking with my brother Brack, who to say the least, absolutely abhors his job. Well, maybe abhor is a little strong, but he is extremely frustrated and unsatisfied. He works at a air force base in the human resource department and he basically helps provide statistical data for departments on who, what, and where to hire new help. Since he is a “wiz” at solving problems, computers, and making this more efficient, he has streamlined his work process with several nifty Excel spreadsheets and Java programs. He can now take a weeks worth of work and do it in one morning.

Needless to say, he is now doing all sorts weird things that aren’t in his job description. Worse, if he isn’t “staying busy” he gets reprimanded by his superiors, since he needs to be “working.” Even though he has done triple the amount of work that his job really entails. His immediate boss and co-workers really enjoy his work, because he helps them out a lot and they see all that he does. Its those hirer than that who don’t both about quality or quantity of work, and just see “if you don’t look busy, you must be slacking off.”

Anyway, he has been exploring other options of employment, and he has decided to experiment with Web Development to see if he would enjoy that line of work. So we’ve been talking about possibilities of teaching him how to do web development, in the hopes that he will pick up on it quickly, and we could soon throw some basic work his way.

</tangent>

So over the last days I’ve been thinking about advice to give aspiring web developers, or those who are looking to improve on their skills. Here is my list of advice (or at least just a few items) to help you out.

Prepare to be a “Self Learner”

If the concept of “learning stuff on your own” doesn’t sound appealing, I’d like to share one crucial piece of information: The majority of your learning will be on your own, doing your own research. Yes, there are classes that can help you learn. Yes, you can get help from other developers. However, 90% of the stuff I’ve learned has been through my own research, study, and experimentation with technologies. The other 10% has been working with others to improve on my 90% I’ve already done. No one is going to take your hand and walk you through each and every lesson you need to learn. No one is going to spoon feed you your answers. You have to be willing to “figure stuff out on your own.”

If this doesn’t sound appealing, I’d highly recommend you re-evaluate your future as a web developer. Its not because you wouldn’t necessarily be good at it, but that the shear volume of new information, techniques and technologies is so vastly great that it would be impossible to have someone else teach you everything.

Web Development is Creativity & Problem Solving

Weh development requires a LOT more problem solving and creativity than people think. The best way to describe it is for most people think web developers are like construction workers. People hand you instructions, and you use your skill set to accomplish the task. Also, many people think each website is basically he same, and so it is like building houses. While they all might look different, the challenges they provide are all the same.

Web development is nothing like that. The best description is it is more like you are the architect, contractor, and construction worker all together. Unless you work for a giant firm, most of the time you’ll be planning how to execute just as must as you do the actual building. If you don’t enjoy this concept, once again you might want to re-evaluate. However, if you love challenges, then web development is for you. It seems every new site has something to bring to the table to make your brain really work.

Don’t Overdose On Information

There is a lot of information out there on web development. While I was explaining it to my brother, I realized that the average LAMP developer had to deal with a lot of technology. Linux, Apache, PHP, MySQL, HTML, CSS, JavaScript, Ajax, and many other things. Each one could give you hours upon hours of information to study. You’d never be done.

Start small and worry about just one topic at a time. If you rush to learn it all, you’ll be overcome with the vast amounts of knowledge you can learn, get overwhelmed, and lose all desire to learn more.

Be Aware Of Many Technologies, Focus On A Few

This can go hand in hand with the previous idea, but learning about a technology is much different than learning how to use one. An example would be Memcached for me. While for years I’ve known about it, I haven’t had a real need to implement it. However, I knew exactly what it was used for: lightening load on databases and improving website performance. So when the time came when I needed what Memcached provided, I knew where to look.

There are many other technologies like this that I haven’t used yet (Comet, Advanced MySQL Replication, Amazon Web Services, etc) but I know of. That way, when I do need them, I know where to look.

Find People, Groups, and Communities to Ask Questions

Find someone you know who can help you answer questions you will have. It is important to have this resource of experience the benefit from, but not abuse. Do your homework and research so you can go to these people with well defined questions, not “I don’t get this, show me.” There isn’t a quicker way to lose the attention of others than wanting them to do your homework for you. While many web developers are willing to share knowledge, we’re not willing to do your research for you.

I recommend finding a local user group, like the Utah PHP Usergroup that you can find people who can help answer questions. There are also national and international groups of people who can help you out. Just remember, be nice and kind to these people. You won’t get anywhere if you’re a jerk.

Don’t Get Discouraged

It can seem like there is a lot of information out there. There always will seem like there are things you should know, but don’t. Keep at it. If you find that you really do enjoy it, keep working hard at it. If you honestly try, and put for hard work, you will get better.

Always Think: How Can I Do This Better?

I think this is severly overlooked by many web developers, and yet it is crucial to their growth as skillful developers. There are always ways to improve, and if you actively seek them, you’re work will get better. Why is this so bloody important? You will spend 80-90% of your time maintaining code and projects rather than writing new code and websites. So if you can write a website that is easy to maintain and has very few bugs, you’ll be loving life. If you continuously spew out garbage, and don’t activately seek more efficient ways to code, you’ll be miserable.

Good Luck

Web development is awesome. I love it, and I believe it can offer a very rewarding career for people who enjoy challenges and use their creative side. I don’t want to discourage anyone from following their dreams, I just believe it is important to have realistic expectations going into it. The last thing you want to do is spend five years learning how to be a web developer, only to find out you do not have a passion for it.

If you ever have any questions, please feel free to leave a comment or contact me. While I don’t know everything, hopefully I can point you in the right direction.

Related posts:

1. Software Development With Clients In Mind
2. Web Development 10-Years Ago & Now
3. Characteristics of Good PHP Code

Related posts:

1. Blog WordPress Theme Experiment – Grunge Style
2. 100th Blog Entry – First Year of Real Blogging
3. Redesigning blog….

I’ve been searching for awhile for a good example for this subject, and when I saw this sketch, I knew this would be perfect. It outlines two large problems with developing solutions for clients: quality & suitability.

In the sketch (transcript avaiable) each architect presented their solution. One was very well designed with high quality in mind. The second solution was well suited for their needs, but obviously has a sub-par quality. Which brings us to the conclusion, which solution did the developers pick? The poorly designed one of course! Why? Suitability, how well somethings fits, comes before quality for consumers and clients.

These seems rather obvious, but in-fact many developers get caught up in quality and then are totally surprised when their clients aren’t happy. Why? Because as developers we notice and respect quality a great deal more than suitability.  However, clients rarely consciously notice quality. Sub-concisely they’ll notice speed, performance, bug-free, etc. However, they don’t really realize it, it is just something they come to expect. If a software solution doesn’t suit their needs as they would like, no matter how high of quality the solution has, clients and consumers will think its poor quality.  So how can we deliver a high quality solution that also is suitable for their needs?

Understanding Needs

Before you can meet a need, you must understand it. I think software development education is severely lacking in helping students learn to understand client needs. There is a lot of education on theory, best practices, and technologies like programing languages and database design. However, at the end of the day, these techniques fall under the “quality” category. Don’t get me wrong, all these skills are extremely important and deserve the time and effort they receive. But what about suitability? I don’t care how well a program is designed and coded if at the end of the day it doesn’t suit my needs.

This is what my current boss calls the “get it” gene. There is so much more to software development and design than just under the hood. Like I’ve said before, clients and consumers don’t really care whats under the hood as long as it is working. For them their number one concern is having their needs met. Have you ever received a specification, followed it exactly, only to have your boss or client turn around and say that it won’t work for their needs? It has happened to me, and its extremely frustrating. It feels like such a waste of work many of the times.

Developers who “get it” do more than follow specifications. They can visualize the people who will use it and understand what they need. Specifications are usually just a good outline, and when following it a developer needs to ask himself these questions as he works:

• What are the needs of my end-user?
• Why are they doing this?
• Is this a practical way to accomplish this task?
• Is it easy to understand and follow?
• How often would they do this task?
• Can they do it in a reasonable amount of time?
• Does this make my client more productive?
• Is this really filling their need?

I know of a software development company where in the 80s they created a software product for video rental stores. They wanted to be different from the rest of the competition. Everyone else used the keyboard as their only method of interfacing with the program. However, the mouse was becoming a popular standard with computers, so they decided they would use the mouse to navigate and execute transactions instead of a keyboard. They worked hard, created their first version, and released it.

There was just one problem: it took a lot longer to use the program than the competition. While one person had to move and click across the screen for just about everything, the competition could quickly use keyboard shortcuts and do the same thing in 1/4 of the time. In a retail store, if it takes 4 times longer to get customer through checkout, it is a serious problem. Not only that, but it was more work moving and clicking the mouse.

In short, while the interface was sleek, elegant, and it was easier to train, it didn’t fit the primary needs of their clients: check out clients quickly. This repetitive task wasn’t quick enough. Imagine if your IM client required 5 steps to send a message. You wouldn’t use it, it would a giant waste of time.

How To Become More Understand

I’ve jotted down a few ways a developer can work on becoming more understanding:

• Meet the Client – I would suggest any key developers who will be working on the client’s project should meet the client. Developers should feel free to ask questions to help them understand better the project. I suggest the developers be briefed first by the project manager, ask him questions first, and then any unanswered questions can be asked to the client. I’ve also believe that putting a face to a name always makes business more personable.
• See the Need – If at all possible developers should go and see the need that they are trying to fulfill. If you’re working on a Point of Sale program for an automobile supplies store, try and visit the client and see where your software will be at work. I remember working on a tool to help prep kiosks for deployment. The client sent pictures of the work area, and the lead developer went to visit the warehouse. See the environment helped the entire team understand the needs and challenges we faced, and helped up create a better product.
• Open Communication – There should be one point of contact with the client where questions can be asked. If there is something you don’t quite understand or isn’t clear, the Project Manager should be able to get answers in a timely fashion to keep things moving along.
• Frequent Client Feedback – This can be a double edge sword, and expectations about “feature-creep” should be set and kept. However, showing the client regular progress is important. Getting feedback during the entire process will actually help eliminate feature-creep at the end. While testing in the Alpha and even Beta stages of the project can be hard, using tools like Camtasia and Jing can help get feedback from clients when change is easier to make instead of a day before the deadline.
• Usability Testing – Try to have an environment that is easy to quickly perform usability testing. This should be done throughout the entire development process. Like I’ve said before, its easy to make small changes as you develop. However, making a lump of changes at the end can be expensive and frustrating.

From jr. developers to project managers, it is important to understand the needs you are supose to fullfill. The reason computers and software has become to popular is its ability to make our lives easier. Focusing on all aspects of software development, and not just the technical aspect, can make the difference between an okay developer and a great one.

Related posts:

1. Great PHP Article: Leadership in Software Development
2. Web Design & The Cookie Jar: When Dealing with Clients
3. Speaking: Utah PHP Usergroup – Streamlined Web Development