I”ve had some performance issues lately with the server buckling under the pressure of a high peak user load . Other times, I”ve had issues with process intensive tasks that kept recursively spawning more instances of themelves.
Creating performance intensive scripts require a good amount of design & architecture forethought, and sometimes you can”t always foresee the ways things could go wrong.
I ended up adding a method to my PHP codebase, is_server_overloaded() , to partially alleviate the problem.
Source Below: (note: only works on linux boxes)
/****************************************/// - Input vars: // - Preconditions: // - Postconditions: // - Returns: server load as a percentage// - Comments: // - // - function getServerLoad() { if(file_exists("/proc/loadavg")) { $Load = file_get_contents("/proc/loadavg"); $Load = explode('' '', $Load); return $Load[0]; } elseif(function_exists("shell_exec")) { $Load = explode('' '', `uptime`); return $Load[count($Load)-1]; } else { return ""; }}
/****************************************/// - Input vars: // - Preconditions: // - Postconditions: // - Returns: bool - true if server is overloaded// - Comments: // - // - function is_server_overloaded(){ return getServerLoad() > 10; }
If your code executes a lot of performance intensive tasks, and you”re starting to hit a lot of scale, you may want to consider using this code to establish an upper limit to the end users experienced load time.
I use this is_server_overloaded() method to establish an upper limit to the level I will push my server, and have a few performance intensive areas of my PHP/MySQL code that are designed to perform differently when a load issue appears (ie. when is_server_overloaded() == true).
I love tools that help me be more productive or more self aware (especially where Time Management is concerned).
What it is. (from Rescuetime.com):
Personal time management software. Get the focus you need to get things done!
Features. (also from Rescuetime.com):
- Automagical app & site tracking (with no data entry!)
- Beautiful time & attention reports for managers only
– goals, alerts, and blocking
I discovered them a few months back. It”s been a fantastic way to introduce a feedback loop into my work that allows me to see where I”m wasting time, when I”m most productive, and when I”m somewhere in between. For example, I”ve learned I have a bad habit of checking facebook, email, and twitter throughout the day. Using their blocking feature, I am able to block those services whilst in delivery mode.
Their interface is smooth. Their widget works fine. I”m pretty happy with their service..
Some data pron, to follow:
Jeff Widman, an old friend from Techstars ”08 writes:
If you heavily rely on analytics, you might miss breakthroughs because you’re so stuck on gradually evolving… how do you balance learning from feedback loops and simply taking a leap with your gut?
My 2 cents:
If you”re tracking the right metrics, and view those analytics as the validation part of your decision making process, and not the entirety of your decision making process, then no.
My team members and I have other input sources for deciding what our priorities are: Our mentors, our board, our analytics, our gut, and subject-specific literature. Our analytics is just one of those inputs. Specifically, it”s the input source that allows us to know if the advice we”re getting from other inputs is both valid for and applicable to our business.
I think if you”re tracking the right metrics, you”re not going to miss your next breakthrough. Conversely, you”re going to be looking at the justification for the decision that causes that breakthrough.
One of the biggest distinctions between my previous corporate job and my role in a startup has been the lack of support and gear immediately available to me in the later.
As a result, I carry around a good deal of gear with me in my travel bag.
Here”s my gear list:
- Macbook Pro
- DVI & VGA Adapters (for presentations)
- Extra MagSafe Adapter & Extension Cord/Plug Multiplier
- 4 GB USB Drive
- iPhone with Tethering Capability (and extra charger) (It”s fantastic to have internet wherever you go!)
- Notebook Lock
- Extra pens, sticky notes, business cards, promotional stickers.
- A digital voice recorder, which is really nice for taking notes on (with permission) lectures and meetings.
I”ve found that the extra gear that I just happen to have with me has saved my tail, or my partners” tails, several times. I guess the old Boy Scouts Motto, Be Prepared, really applies when traveling/pitching/presenting in the world of entrepreneurship. I like to think of that laptop bag as my digital swiss army knife or my digital utility belt, and my attitude towards traveling as ”Be a digital boy scout. Be prepared”.
What does your travel bag look like ? What gear have you found handy to have around in a pinch?
— This post is part of a series of ongoing tips on lessons learned & experiences I”ve had as the lead developer of the online dating startup, at Ignighter.com. Though these tips are focused primary at consumer startups, they ring true elsewhere too. For a full list of these tips, see 10 things I”d wish I”d known as a lead developer at Techstars. —
I spend a lot of time worrying about how my system is going to scale. The next time we get that big press piece or hit some load issue, I want to make sure that I have a plan in place.
Build for Scalability
I”ve collected a small bag of tricks to help the performance of my application (which is coded in PHP, MySQL and jQuery).
- Learn how to use MySQL indexing.
- Use include(); sparingly (PHP only).
- Use Memcache in your database layer.
- Use front-end hacks like far-futures expires headers, CSS sprites, and image maps.
- Perhaps this goes without saying, but: Make sure your code-architecture is de-coupled and highly logically-cohesive. More on this here.
- Prepare your database architecture for scalability. This post, by Digg”s Joe Stump, does a good job of laying out their database architecture.
Beware of premature optimization
Sometimes you bend over backwards to make sure a new feature is entirely scalable, and when you launch, nobody (or almost nobody) uses it.
You may not know for sure which features your users are going to use heavily. You could have a hunch, but you don”t know for sure until you launch that new feature.
It”s a balance, for sure. I don”t know that I have the magic formula. But, I think I”ve struck a good balance by considering which features are critical/central to the system, building for scalability, being careful not to make any short-sighted design decisions, writing good documentation, and following my instincts.
In the spirit of giving credit where it”s due, I”d like to mention that Eventvue”s Josh Fraser gave me the idea for this post during my time in Boulder last month. Check out his blog, Online Aspect, for his musings on his adventures at Event Vue.
— This post is part of a series of ongoing tips on lessons learned & experiences I”ve had as the lead developer of the online dating startup, at Ignighter.com. Though these tips are focused primary at consumer startups, they ring true elsewhere too. For a full list of these tips, see 10 things I”d wish I”d known as a lead developer at Techstars. —
I spend a lot of time building and reading reports. I also spent a lot of time shuffling files around, and formatting data.
If you”re like me, you probably also spend a great deal of time doing simple, mindless, monotonous tasks like normalizing data, working with log files, or transferring files from one development region to another. While they are completely necessary, these simple mindless tasks take a ~long~ time.
One of my favorite things to do when executing these types of tasks is to figure out where I can eliminate the inefficiencies in my process. Since I”m running a startup, and am not subject to the process of some large bureaucracy, the power (and responsibility) to optimize time-inefficient tasks falls with me.
What types of tasks I automate
Most of the time, this process starts with a task that I have to do twice. The first time I do it, I groan, but I suck it up and do it the brute force way. The second time, I look for a pattern to emerge, and if one exists, I write a script to do the bulk of the work for me.
Part of the fun with this approach is that, while you are performing a mindless task, you can let your mind wander about the ways you could be improving your workflow.
Tools of the trade
If you aren”t familiar with shell scripting, you probably should be. If you”re on the LAMP stack, get to know your cron tab. Also, QTP is a great tool for Windows UI automation.
Some Use Cases
Here are a few examples of time-saving scripts I”ve written. In the past, I”ve written scripts that
- Build Regions.
- Normalize Data into JSON, MySQL, or XML formats.
- Build cached versions of my codebase.
- Find Database Integrity issues, correct them, and notify me so I can investigate deeper.
- Backup my codebase and database.
- Comb my log files for a search query.
- Email daily, weekly, and monthly statistics reports to my team.
Bottom Line
It”s a best-practice to always be looking for ways to optimize your processes.
How much time could you save if you automated your repetitive tasks today?
— This post is part of a series of ongoing tips on lessons learned & experiences I”ve had as the lead developer (CTO if you want to be fancy) of the online dating startup, Ignighter.com. Though these tips are focused primary at consumer startups, they ring true elsewhere too. For a full list of these tips, see 10 things I”d wish I”d known as a lead developer at Techstars. —
One of the biggest differences between writing code at school and writing code today has been the need to work with, interpret, modify and/or rewrite code that my teammates have implemented.
It”s been a humbling experience, to say the least.
Everyone has their own habits, their own rhythms, and their own way of thinking about code patterns & implementations.
And when you don”t draw a line in the sand upfront, things can get messy, really, really quick.
So, one of the biggest boons to team morale (not to mention, my sanity), in the last 12 months, was when the team, together, developed coding standards to adhere to.
And the biggest boon was when we actually started following them.
Here are the standards that, in my experience, have been the most helpful in keeping both team morale & team sanity up:
- Introduce indentation standards. It” really simple. Just nest if statements, loops, and function declarations with tab indents. It allows my eyes to scan code 3x faster than when for loops, if statements, and methods aren”t indented. And that”s just fantastic.
- Comment every method you create. We list the preconditions, postconditions, return variables, and input variables for each method in our code base. We have a standard comment template that is already formatted to receive these values. Here”s what it looks like:/*********************************************************/
// - Input vars:
// - Preconditions:
// - Postconditions:
// - Returns:
// - Comments:
// -
// -
function Name($InputA,$InputB,$InputC,...) {
//Method code goes here
}
- Introduce variable & method naming standards. Simple standards around how you name your variables can help code readability a lot. Start with simple things like what to do with individual words in variable names ($AVar or $avar?), whitespace ($A_Var or $AVar?), upper & lower limits on length.
- Make code granular & reusable. This is another one that sounds like a no-brainer, but in practice sometimes it”s a hard one to stick to. There”s an entire body of academic research on why your code should be de-coupled and cohesive.
- Find & follow a standard design pattern. The nice thing about design patterns is that someone has thought out the common issues and written rules for you to follow. For me, Model-View-Controller has made my life so much easier. If you”re writing a web app, that”s probably the main design pattern you”ll want to familiar with.
- Peer architect. I like the practice of talking over solutions with teammates before I implement them. It”s a useful way to lay out your design theory and test your assumptions, before you actually write a lick of code
There you have it. I”d be interested in hearing what standards your team has developed, and how you enforce them / make sure you stick with them.
Oh, and if you want to follow musings of the awesome development team I work with, please do so here: @nleach @aycaaksu @maxstoller @maxmeyers, and @zeve .
— This post is part of a series of ongoing tips on lessons learned & experiences I”ve had as the lead developer (CTO if you want to be fancy) of the online dating startup, at Ignighter.com. Though these tips are focused primary at consumer-focused startups, they ring true elsewhere too. For a full list of these tips, see 10 things I”d wish I”d known as a lead developer at Techstars. —
One of the most crucial things our team did over the last year was adhere to a rhymic development schedule:
Every Monday, we release code from our development region, to our production region. For the rest of the week, we analyze our business requirements, design accordingly, and implement new features in our development region.
This allows us draw a line in the sand when it comes to prioritizing features. It allows you set firm targets and deadlines. Abstract questions like “Is feature X more important than feature Y?” become more practical. The conversation becomes: “Can you get both feature X AND feature Y into the release on Monday?” , “No? Ok, how about just feature Y, then?”.
It also allows us to break projects into manageable chunks to iterate on week over week. Iterating, measuring results, and repeat. It”s a fantastic way to stay agile. And staying nimble & agile is the goal for the development team when you”re trying to find the ~right~ product for your market.
On to the details:
What day do you release?
We”ve had a lot of internal debate on what day of the week to release. We chose Monday because it allows us to start fresh and focus on new priorities for the week (Provided there were no issues with the push).
How long should your iteration cycle be?
My team releases weekly. I”ve heard stories of many other startups who release weekly. Some release daily. I”ve found that the overhead involved with pushing code live is too great when pushing on a daily schedule. Anything over a week, and I”m concerned that we aren”t iterating fast enough.
How much effort do you contribute to QA?
Quality assurance is a major concern when you”re developing a consumer app. In my opinion, it”s best to design multiple levels of QA into your process, executed throughout the week. A suite of unit tests helps to catch bugs introduced throughout the course of a week. Next, each team member is expected to troubleshoot and certify their own features by release time. We also do a weekly QA session in which we catch bugs before we do the push.
Do you follow any ”development methodologies”?
No. For now, we”re wary of adding too much process too early in our company. Though, we do regularly study our process and evolve it as needed. Agile looks like an interesting option for the future. As does Lean Programming.
All in all, your release rhythm will probably depend a lot on your product, market, and most importantly, your team. When making decisions about your development rhythm, start with the low hanging fruit, like ”How long do we want our cycles to be?”, and ”What time of the day/week/month/quarter do we want to release?”, and move on from there.
Oh, and don”t forget to have a fun through the process. One of my favorite parts of being in a small team are the fun little events (LAN parties, dinners, lunches, etc..) that we schedule to celebrate a big release.
It”s been about 4 months since I discontinued StartupComix.com, a side project where I had created daily comics about startup-isms, technology, and hacker life.
Initially, the idea was the share ideas, make jokes, and be involved in the hacker community. The idea was heavily inspired by Awkward Rules, xKcd, and Abtruse Goose. It was way harder than I thought it”d be. Especially as a side project. In the end, I discontinued the project as a result of a) a lack of motivation and b) a lack of inspiration.
Here”s a few unexpected things that happened, and the lessons I learned from it:
I overcommitted. From the start, I promised new comics 5 days a week. That turned out to be too much, especially for a newbie author who has little experience creating creative content. I found myself running out of energy to create good content, and I think I settled for some punch-lines that weren”t my best. I think, next time, a better strategy may be to just publish as the content comes to me.
Good content is not easy to create. I”ve come to think that humour is one of those things that is easy to understand, but hard to create. It”s really really tough to create good content on a consistent basis. To do so, you need to continually search for inspiration, even when you don”t want to.
It”s hard to fight a war on two fronts. My work at Ignighter comes first. When you”re giving 100% to something, it”s difficult to contribute more energy to a side project.
All in all, I”m glad I did it. I had some fun times and shared some laughs.
Here”s some of my favorite startupcomix:
Please forgive the formatting. I wanted them to be readable here, but couldn”t find a way to do that and still make them fit within the content area.
- 0×13 – Be careful you don”t get a PWI
- 0√ó7 – Precisely, how long until Google controls everything around us?
- 0×2 РI’m a PC, and I (insert quippy remark here)
- 0√ó14 – Top Ramen, the food of kings.
- 0√ó18 – E! True Interview Story. The Awkward Interview Question.
- 0√ó19 – Did you hear about the guy who was born on January 1 1970?
Team @ignighter spent this past weekend in Boulder, visiting our mentors & friends from last summers Techstars program. It”s been exactly one year since we made the trek from the east coast to Boulder, joining the 2008 mentorship program.
Wow. what a weekend.
I”d forgotten how much Boulder is the type of place that will just humble you. Beyond the natural beauty in the town & the energy of the hundreds of people hanging out on Pearl st for the Boulder Creekfest and BolderBoulder this weekend, I was completely re-envigorated & energized by the technology community in this town.
We kicked off the weekend by meeting with David Cohen, Dave Morin, and speaking on a panel about do”s & don”ts for the Techstars summer program. Afterwards, the team went out to dinner with EventVue, Foodzie, Brett Jackson, and Occipital. Other highlights of the weekend were the Tee & Cakes Cupcake eating contest, in which Boulder”s own Micah Baldwin placed 3rd, and hanging out with the 2009 Techstars teams on Saturday afternoon.
I”d forgotten how fantastic it is to just connect with people who are doing what you”re doing, starting a new web community from scratch. The tech community here is passionate and energetic. They are humble, but they are bold. It”s amazing how much the tech community in Boulder has grown over the past several years, given the leadership of some of the established folks in the area.
I”m thinking a lot about community, lately. I think that, maybe, technology”s biggest offering in a globalized world could be it”s ability to connect us to others around common interests, hobbies, or passions. I”m thrilled to be building a platform for a community of people who are passionate about meeting new interesting people at Ignighter. And, it”s a lot of fun.
