Why Segregate Production and Staging

February 16th, 2014

I purposely didn’t specify server and environments. It’s EXTREMELY important that the staging environment isn’t sharing the same box as the production box.

A good staging box perfectly mirrors the production box, you’d imagine, that it’d be two birds with one stone, if you simply create a staging environment on the production machine. This is an extremely risky and bad idea.

The staging environment is for testing, all sorts of crazy things can happen, from installing hacked code, to code that are so inefficiently coded that the web server and the connecting database server’s load goes out of control. When this happens, sales will be lost, data won’t transmit, and there will be a definite cost to business.

So when weighing the convenience versus the cost, having a staging environment on a production environment is almost never worth the cost.

Know Your Strengths and Weaknesses

February 16th, 2014

Nobody in this world can do EVERYTHING, but there are specialist in everything among us. Just like free-trade theory, if specialist engage in work trade, both parties benefit.

This is why it’s important to understand the things you are reasonably capable of doing, and things you aren’t. Then you can harness other people’s specialties.

This is a critical step. If you are under the impression that you’re the specialist in everything, then you’ll come to the conclusion that all work, in order to be completely efficiency, must be undergone by you. This is simply not scalable.

Sure, perhaps in a single person’s man-hours, it might be more efficient, but it will ultimately result in the project taking much longer to deliver than necessary.

None of us is perfect, but it’s the concept of working together to achieve a greater goal that’s been at the core of civilizations’ success and prosperity. Learn to lean and learn to lead.

Management

December 12th, 2013

There are two types of management, managing for a field you’re familiar with, and managing for a field you’re not.

In the case of managing for a field you’re familiar with, you’re going to leverage a lot of your experience and expertise to make decisions.

In the case of managing for a field you’re not familiar with, you are going to rely on your people assessment skill, your surveying skill, and intuition. Do note, that if you’re going to hire someone to be an expert in the field, and constantly doubting his work, then you need to one, either hire a new person, get some training in the field so you can ascertain whether or not doing his job properly (but then you’ll be micromanaging; doing your job and their job), and finally you can keep your ears open to see if there are disagreements with the approach.

It’s important to realize what type of management the organization hired you for, so you know if you’re managing the way they expect you to. In a way, we’re all cogs in a larger machine, if we’re fulfilling our purpose, things will run smoothly, if we’re not, there are going to be hiccups.

Harsh on self, Harsh on others

December 6th, 2013

I realize that in my world, there is working or broken, completed or incomplete, one or zero. A delivery is not complete until it is delivered and proven working, until then, it’s incomplete.

I don’t like making promises until I’m relatively certain that it can be delivered, and this certainty can only be obtained through testing. Just like a test, either the assertion is met, or the assertion failed.

I don’t like building systems that are prone to breakage, and not doing a thing about attempting to avoid them. It makes me feel negligent. Fixing a bug that I incidentally introduce doesn’t feel like an accomplishment, it feels like a failure.

Every single system I touch, every single line of code I contribute, I have a sense of fondness for it. To me, computer systems are like children. You groom and shape them into exactly what they’ll be. Sometimes, they’ll take on a life much bigger than the life you anticipated, and when they’re able to withstand the battery that’s the real-world, you feel a sense of pride that it was YOU who brought it into this world.

I ponder if I’m being harsh, or am I just following best-practices.

If I’m the person in charge of handling a project, or a delivery, and it doesn’t meet my criteria of code and system integrity, then it’s like asking me to violate my own principles. Not only am I violating my principles, it’s likely that the violations will result in much more headaches and time expenditures than originally allocated. Such requests are inconsiderate and insulting, especially if you acknowledge that you know the consequences of such violations. Perhaps the reason why I find it so irritating is that I expect them to understand the principles I live by, and for the most part, everyone should. You’re either alive or your dead (medical), you’re either in the black or the red (finance), you either got paid or you didn’t (human resources), your system entire works entirely or it doesn’t (code); It’s not so abstract of a concept really.

So am I being harsh on myself and others, or am I just being normal, and others are being extra lax? It’s something to think about, but I say I’m being normal.

Testing, Delivery, and Confidence

December 4th, 2013

I’m often asked regarding how likely a code deployment will deliver the expected results. It’s actually a very simplistic formula, the answer is a neutral answer, but people often think of it as either over positive, or over negative, more frequently the later.

Chance of delivering on time is a function of: testing, how recent the tests are, how close the test matches the production system, and the points of failure.

Obviously, by on time, we’re assuming we’re delivering the functionality the client expected to have by a certain date.

A delivery that has no testing, server systems are widely different, and there are many points of failure, have little chance of being a successful one, doesn’t mean it can’t happen. A delivery that has testing, matching server configurations, and little to no points of failure, has a huge chance of being a successful one, but doesn’t it’s guaranteed.

I know I speak for a few, possibly not for all, but developers wouldn’t feel comfortable with the deploy until it’s been released onto production, stress tested by the public, performed as expected, and then, their hearts are finally at ease. This, is also a form of testing, the final one. Even then, in the back of their minds, they’re thinking that the code could’ve been better, there are edge cases it didn’t cover, and so on. We are forever doomed by a feeling of insecurity, the only thing we can say is that we’ve rigorously tested the crap out of it because, fact of the matter, bugs are a fact of life.

Responsive Design: Fixing misconceptions

October 13th, 2013

I’m exposed to more of the web than most people, not only on the usage front, but also from the development front. A lot of people employ a technique called “word salad”. Roughly, the spout a bunch of words, and pray that they have some sort of meaningful connotation.

One of these words is “responsive design”. Truthfully, “responsive design” meaning should be closest to “fluid design”, which is to develop a site that look “right” on different browser sizes and resolution.

One interpretation of responsive design seems to be, develop a webpage, that if the user switches from desktop, to tablet, to mobile, things will look the same, and the user will have the same experience.

That interpretation is absolutely wrong. If anything, the better statement would be mobile-tablet-desktop-friendly-architecture-with-relevant-designs. Fact of the matter, if you’re website is image intensive, 5 megabytes of image intensive, even if you employed the most advance fluid layout techniques, it WILL NOT be a good mobile device experience.

The main thing to take into consideration is bandwidth. Most likely the user is viewing the site using a 3G, 4G connection, and even then, not everyone has access to 25+ mbps wifi line.

Instead of creating one design that will magically work for all 3, I say design 3 versions that are designed for a specific experience. If you design for desktop, tablet and mobile miss out. If you design for mobile, the tablet and pc version is lacking. If you design for tablet, you’re kind of stuck in the middle, with a mobile device that has a slow experience, and a desktop version that has an underwhelming experience, since it could’ve been so much more.

I think if possible, we should stick to the terms “mobile design”, “tablet design”, and “desktop design”, and the “responsive” versions of each. If the web would adopt this, I’m sure a lot of people who do work in the web will be saved a lot of headaches, where requirements just seem to crawl out of nowhere, rendering existing architectures less effective at the very last stages of development.

Happiness Ladder

September 3rd, 2013

In my limited perception of the world, I find it interesting. The workers are always looking up at their boss thinking, man, he’s made it. The boss is looking at his boss, and concluding the same thing. For the most part, unless you’re at the very top of the chain, you’re still looking up. Even at the top, you might be looking towards the past for inspiration, comparing yourself to historic figures.

It might sound obvious, but if you were to compare yourself to the people less fortunate than you, you are much better off, but if you compare yourself to a person ahead of you, you feel far behind.

I just think it’s important to realize that as long as your basic needs are covered, everything else is just a plus. It’s important to be content with what you have, but desire upward mobility simply for the sake as a challenge to yourself. It’s not a goal you must met, but a goal you can entertain yourself with. Much like playing a game, that you may or may not win. Sometimes, it’s not winning that’s important, it’s the experience of the game.

The Ten Commandments of Project Management

August 24th, 2013

Following at least these 10 commandments will be a big step towards becoming a well-respected, trusted, and optimal project manager:

  1. Always treat the person that’s working with you with respect.
  2. Always assume that your team is working as hard as they can, as fast as they can, and as well as they can.
  3. Always ask how long things are going to take, never assume.
  4. Code WILL break, it’s just a matter of WHEN.
  5. Describe tasks so even a person who’s never been on the project can figure it out.
  6. Angry, sad, and annoyed team members are non-optimal team members.
  7. The larger the project, the longer the estimate, the more likely it is for the estimate to be wrong.
  8. Anger is a sign of losing control, and not a sign of assertiveness.
  9. Let your team do what they do best, remove obstacles that can get in their way, provide support whenever possible.
  10. Always recount the things your team members did, and thank for the efforts it took to get it done.

There’s more to management than numbers. There’s more to communicate than words. There’s more to life than just work. A project manager is a person placed in a very important role, a bad PM can spell the death of an entire project, a good PM can be at the heart of it’s success. Learn the strengths and weaknesses of your team, and learn to harness their strengths, and try to reinforce their weakness. You catch more bees with honey than vinegar. A happy team is an efficient team, and you’re often times that’s exactly what you want.

Invest in Your Business: Time is Money

May 28th, 2013

Everybody knows time is money, but it seems to be a very important concept that seems to escape a lot of developers’ mind as we strive towards code utopia. One of the strengths of developers as Larry Wall, the father of Perl, has put it, is laziness. We’re willing to go through great distances to save time in the long run. We invest into infrastructure so that we can benefit from it in the future. This causes us to obsess over frameworks, languages, plugins, coding standards, documentation, and so on.

One key thing to remember as a programmer is: “time is money”. The ultimate law of an employee is that you must bring in, in one form or another, more money than you cost. If that’s not the case, the company can quickly go out of business, or you become a burden on the resources and less of an asset. Sometimes, as a developer, we need to take a step back, and think “What does business what? What does business need? What WILL they need? How are the investments I’m making going to further that?” Often times, the code infrastructure investment doesn’t.

For example, if we decide to port the javascript over from one js library onto the next, and it cost the entire development team a couple of weeks to port, a week to test, and another week to put out all the fires that occurred because of the port. To developers, they might think, “Yes! Now everything is on a more modern javascript framework, we might get more cool stuff for free from now on, or it’s less likely to break. We can do javascript faster now!”

From the business standpoint, “We just lost a month worth of development time, and ALL these bugs just came out of nowhere! Our competitors just launched X! We need to gain ground!”

As developers, we need to understand that we’re playing a support role, a significant support role, but a support role nonetheless. We need to be more of an asset and less of a liability. We’re helping to keep a ship sailing. When we make our time investments we need to not only make it from our the perspective of making developers lives easier, but also whether or not that type of investment is even an option for the business. As a developer we are often times protected against all the business craziness so we can focus on our work, but at the same time, I do believe that exposure to such business requirements can help us better align how we use our time a bit more appropriately. At the end of the day, if the ship sinks, what good are all those technology investments we made?

Drupal 7 Changing Update Manager FTP

February 14th, 2013

I had a hard time finding this information, and eventually, I got to where I needed to be. The following URL should be more than sufficient to help guide others to the right direction.

 

http://[site]/authorize.php