Sex: Male

Age: 46

Today's Date:
Dec 3, 2021 - 1:54 am

Viewing all 11 entries.


Viewed 21289 times.

Add a Comment

Return to Web Site.

Recent Entries

Last 5 Entries

ALL Entries

Subscribe to RSS Feed

April 2007






Online Store

Hall of Fame


Server List

About Profiles

About the Game

Contact Us



Forgot Password

Create A New Profile

Favorite Links

Hosted By
Hosted by OZNet

  Title: The Proper Care and Feeding of Software Applications
Apr 17, 2007 - 2:49 pm
Posted By: Ak5intoe


I work for a very successful Fortune 500 Company. We have numerous applications that we develop and maintain. In particular I work on a product that brings in about 25 million a year. On a fairly regular basis I perform maintenance on the application. This mostly involves finding and fixing defects within the software. It always amazes me that given the state of the code the product makes the revenue it does. It?s been neglected for so long that many areas in the application require superhuman efforts just to maintain it.

I?ve spent a fair amount of time reflecting on why the code is in such a terrible state. Did the original developers not care or did they not know any better?  I?d like to think the source of the problem is the latter. Had they known better, I suspect they would have properly cared for the application. Yet, the past is what it is and the code is in the state that it is.

As a developer who does know better I find myself with a rather large predicament. I?m often tempted to jump in, make my fix, and jump back out without performing any sort of maintenance. I call this bungee maintenance. However, that won?t help the product, my team members, or the customers who use the product.

To solve the problems and to properly care for my application I need to be continuously refactoring. There are many articles and books that have been written on the subject. The goal of this paper is to discuss the most common type of problems I see in the code. I suspect they are the most common because they are the easiest to create and come naturally to new developers.

Unless you?ve been living in a cave you?ve heard the term, refactoring. In case you haven?t I?ll quickly define it. Refactoring is the process of rewriting code in order to improve its structure without changing its behavior.

Many of you may be refactoring today without realizing this is what you are doing. Have you ever looked at a method or class and thought, ?This could be written better,? and then actually changed the design of the code? If so, then you?ve refactored.

Code Smells

Before we go any further, it would be a good idea for another concept to be introduced. This concept is the ?code smell?. I think everyone has heard at least one time or another that a certain piece of code ?stinks?. Code smells now give us a means to describe why the code stinks.

Duplicate Code

The first smell we want to discuss is the duplicate code smell. This is probably the most common smell you will find in an application. You can probably guess what this smell is all about from the name. Any time there are duplicate sections of code in an application there is the potential of duplicate code smell.

Duplicate code is often the result of someone identifying a piece of functionality the software has in one location that the software now needs in another location. The quickest way to implement the change is to copy the code from location A to location B. The end result may be what the developer wanted, but now a problem has been introduced into the application.

Let?s assume the functionality that was copied contained a bug. It?s sometime later before the Quality & Analysis (QA) department finds and logs the bug. A developer is then assigned to fix the bug. The area in question is quickly found by following the steps laid out by the QA engineer and the developer fixes the bug. However, because there is another copy of the code, the bug was not fixed there. It will have to wait until that particular issue is identified once again.

On the other hand, maybe the code was perfect but now its functionality needs to be expanded. Once again, if the developer does not locate all sections of the duplicate code then a problem is introduced into the software. It won?t be long before someone points out the inconsistent behavior.

Fortunately for the developer, this smell normally has a simple solution. The toughest part normally is identifying the duplicate sections of code to begin with. While some sections may be exact copies, others may perform the same logic but go about it differently.

Once the duplicate sections have been identified the fix is usually just a matter of creating a method that does the same functionality as the copies of code. When that?s been accomplished the developer can then remove the duplicate sections and replace them with a call to the new method.

procedure CalculateTotalPrice;
  price := price * quantity;
  totalPrice := formatFloat('$###.##', price/100);

procedure CalculateTotalCost;
  cost := cost * quantity;
  totalCost := formatFloat('$###.##', cost/100);

We have two methods: CalculateTotalPrice and CalulateTotalCost. Both take an integer value, convert it to a float, and then format it as a string with a currency symbol.

While this particular example is small it works well to illustrate the point. Suppose the product is being introduced to Europe and rather than using the dollar sign you now have to use the symbol for the pound. Or perhaps the particular product is being expanded to support gas stations and the price and cost now needs to show 3 decimals instead of the two currently being shown.

We could solve the first problem by making the currency symbol a constant. However, we?ll ignore that solution and leave it the way it is.

First we need to create a new method that contains the duplicate code. I?ve called it CurrtoString

function CurrToString(value:integer): string;
  result := formatFloat('?###.###', value/1000);

Notice that both changes have been implemented in the new method. I?ve replaced the dollar sign with the pound and changed the formula to include three decimal points.

Next we need to replace the original sections of code with a call to the new method, CurrToString.

procedure CalculatePrice;
  price := price * quantity;
  sPrice := CurrToString(price);

procedure CalculateCost;
  cost := cost * quantity;
  sCost := CurrToString(cost);

There is now just one method that controls the converting of a currency field into its string representation. In the future, should something have to change, the developer only has to worry about the one method rather than possible copies that might be lurking about.

Long Method

The long method smell is also a common smell that exists in many software applications. This smell is often introduced when new functionality needs to be added to the software.

It goes something like this: There is a method that performs some sort of functionality. The project manager decides the application would better meet the needs of the customer if the functionality were extended. The assigned developer finds the method that performs the existing functionality and proceeds to add the new functionality. While in some cases this is appropriate, in many the developer is creating a long method.

This becomes a smell for several reasons. The first is that long methods are harder to debug. They often contain different levels of abstraction, which makes reading the code harder. They also tend to scroll off the screen which can become a problem if you can?t see the closing symbol for a particular block of code. Lastly, the method name becomes less descriptive of the process the method performs. Before the method name was DoSomething,  It now needs to be changed to DoSomethingAndSomethingElse.

To fix this the developer needs to look at the method and decide the proper course of action. This might be as simple as just extracting pieces of the long method and making a new method, or it might entail the creation of a new class or classes!

In our example DoSomethingAndSomethingElse, you can see that there is a conditional block that was added to the bottom of the method.

(In real life this method would be longer and probably more complex)
procedure DoSomeThingAndSomethingElse;
  if someCondition then

In this particular example the fix is rather straightforward. At a minimum the code inside the added conditional block needs to be extracted into it?s own method. Then a call to that new method needs to be made from the DoSomeThingAndSomethingElse method.

As an alternative solution you may have put everything before the conditional block into its own method and the conditional block itself into a separate method. In this scenario our method DoSomeThingAndSomeThingElse now has two method calls.

procedure DoSomeThingAndSomeThingElse;

The goal here is to reduce the length of the method and maintain a consistent level of abstraction. Often times each instance of this smell will require a unique solution.

By keeping your methods short, free of conditional complexity, and containing the same level of abstraction you can ensure that your method will be easy to maintain and understand.


These two code smells are most common smells that I run across and they are the source of many defects. You may be asking how a long method, duplicate code, or any other smell is the source of a defect. The code itself may be perfect and runs just fine, so how can it cause problems? The problem is that it increases the complexity of the code. It makes it harder to figure out what?s going on and therefore it creates an environment in which it?s easy to introduce defects.

We only covered two particular smells. There are many, many more. You should train yourself to identify them all. You should also know how to solve each one. Only then will the software you write maintain the elegance and style that it was created with.


If you?re looking for more smells you can find some lists here:

There are also some great books out there that discuss in depth some of the complex smells and the solutions needed to fix them.
?Refactoring To Patterns? by Joshua Kerievsky
?Refactoring? by Martin Fowler

  Title: Far from home
Apr 1, 2007 - 6:02 pm
Posted By: Ak5intoe

The torpedo left the bay and streaked towards a giant interstellar gas cloud. As it reached the center of the could a wildly bright light flashed from the torpedo as it exploded. In an instant the light was gone as the energy released increased out of the visible spectrum. What was visible was the effect on the gas cloud. Slowly, the center of the cloud began to condense and collect. Zbop was witnessing a marvel of mankind?s technological achievement. No matter how many times she saw it, the process of creating a planet always amazed her. Humans definitely were admirable, she thought, even if they were a scourge she was going to destroy.

Zbop scanned the initial reports coming. The orbit was steady and planet appeared to holding together. Elemental composites were as expected. This was good. ?Send the terraformers? she ordered. ?Send the terraformers? the operations officer repeated.

Moments later several enormously large ships separated from the fleet and headed towards the freshly created planet. Their work would take many months to complete, but at the end it would be a beautiful planet supporting life.

Zbop watched with pride as the terraformers entered orbit around the new planet. She had been at this for many decades now. In the back of her mind she wondered if they would come again. No, she decided, we?re well hidden and well protected. It will never happen again!


Generations had passed since the last encounter in which The Hive had almost been annihilated in a great and tremendous war. For seven years Admiral Ak5intoe and his fleet continuously battled the superior numbers and forces of The Hive. The human solution was to be final and nothing was spared. One by one as they fell, the planets of The Hive burned and were destroyed.

Eventually, the Admiral surrounded Zbop?s, or the Queen as her subjects call her, home planet. The ensuing battle was a meat grinder. Planetary defenses were strong. For days the fleet and the planet traded fire causing heavy losses with the fleet sustaining the most. At a pivotal moment in the battle, the Admiral entered low orbit and blasted the beams from his capital ship at point blank range against the planetary shields. Separated from the fleet and unprotected this was a dangerous moment. The beams collided with the shields surrounding the planet. At first nothing happened, but then a shimmer appeared in the shields and pulsated in unison with the beams. Fortunately, for the Admiral, this dangerous move paid off. The shields failed and the beams hit the surface destroying the generators and dropping planetary defenses. At that moment a small craft left the surface of the planet and entered a low orbit. The fleet moved to engage but before the fighters and missiles could intercept the ship it engaged it?s light drives and entered sub space. Planetary reconnaissance later confirmed what the Admiral and all of humanity feared. Zbop had escaped.


Current Day

Lieutenant MacGregor sat at his assigned station dutifully performing his work. As a science officer one wouldn?t describe his occupation as exciting or interesting. However, one would describe it as vitally important. He and the other science officers were searching for the location of their sworn enemy.

?Hmm? he thought. ?Is this accurate??

?Sir, one of our probes is reporting a growing gravitational disturbance on the outer edges of space. I?ve checked it against archived scans in the area and there?s something defiantly happening out there. Computer analysis shows an increased gravitational density of at least 50 planetary masses.?

Admiral Guts smiled. ?Good work Lieutenant. I think you?ve just found The Hive. It was only a matter of time before their imperialist expansionism gave them away.?

?Mr. Gata, order the fleet to prepare for an immediate jump? the Admiral stated. At that command the bridge began to buzz with activity. Even the queen would have been impressed at the disciplined response that was now readying the fleet for combat. Within moment?s, ships within the fleet were reporting that they were ready to jump.

?Leiutenant McGregor, give the helm coordinates for the jump?.

?Coordinates received? the helm responded.

Admiral Guts smiled as he ordered ?Prepare to jump?.Jump?.

At that moment the largest armada ever assembled by man left. Each ship tore a small hole in subspace entered. As the hole collapsed it released a bright light signaling that the ship had passed.  What awaited them on the other side was unknown.

Entry Edited 1 time - Edited on Apr 6, 2007 - 12:06 am

  Title: Viridian Room
Aug 4, 2005 - 1:23 am
Posted By: Ak5intoe

Ok this one was much tougher and took over an hour. One of those pieces of paper was tough to fine. Plus it took me a while to realize the value of a cold beer

Langel.. post more.

  Title: Crimson Room
Aug 4, 2005 - 12:07 am
Posted By: Ak5intoe

I gave Langel's Crimson Room a whirl


It took roughly 25 minutes (maybe a couple less) to beat.

I'm by no means a gensis so I think the rankings chart may need a bit of tweaking. Anyway, it was entertaining. Give it a whirl yourself.

  Title: Draft Tourney Spring 05
Jun 6, 2005 - 2:09 pm
Posted By: Ak5intoe

I told everyone I?d post my thoughts regarding the team tourney so here they are.

To begin with I think some teams were luckier than others during the draft. My strategy was to get a couple of good attackers and a couple of good builders. As such my goal was to get Big, SLIM, YOYO and Nambia. Three out of four wasn?t bad. Nambia is an excellent builder and I wish we would have gotten him, but I felt comfortable with what I had. I also wanted people whom I?d seen spend a lot of time online.

The team that probably fared the worst was Ares?s. I really can?t fault him though, he was drafting players he knew very little about. As a result he got a big grab bag.

Once the tourney got going we were off to a rocky start. We had started a snowball and it was going nicely until it was completely lost. Myself, Barrow Warden, and Langel and YOYO did what we could to get it going again. By then Barrow Warden and I had completely spent our turns. About this time Big made his first appearance and was off to a great start thanks to the snowball. Likewise SLIM was doing very well despite his planets having been sucked dry of cash.

It was only a day or so before we were able to start naving nests and performing sequential rs searches. From then on, we started smashing the opposing teams, Slim just went nuts. At 10k sectors there wasn?t really any place for the other players to hide, and the body count was steadily rising (I always got a good laugh at doing a long range scan to sector 1 and seeing the ship / pod count) . This gave our builders and newbies a chance to build in relative peace. YOYO is a building machine, he had nests all over the place.

Before the tourney started I envisioned us carrying out assigned tasks and working really hard together as a team. Our lead was so large though that I pretty much just let people go and do what they wanted.

I want to congratulate those on the opposing teams that stuck it out especially Nambia. It?s not easy to start over every other day. Oakman?s team also did very well considering it was only him and maybe two others that were playing. Same with Wraith?s.

  Title: Tourney
Mar 24, 2005 - 2:10 am
Posted By: Ak5intoe

I won the 2005 tourney.. go Rangers

It really wasn't that tough (I think the comments in this blog could just as eaisly come from Oakman). I was a bit worried about Ramasi going into it, but he ran in to Oakman and some badluck (not the player) early on. The others weren't used to a realy aggresive style of play and began getting podded left and right.

My favorite pod was probably Fantaz. I was looking to get even for all the planets and SG he left in main. He had been parked in his super cargo in sector 2 for days, so I was just waiting for him to log in. As soon as he logged on he hit a mine within a minute or two (see below). Seconds later I hit him, and he left the game.

The scarriest moment was when I almost lost my voyager with just a day left (I was eating lunch, reading email, and trying to play at the same time... hit some indy SD). I went from a 2.5 M point lead to 3rd place. It took a lot of building to get back up. One of the bonuses of a damaged ship is that it takes half the credits to reapair it but you get full point value.

I gotta give a hand to Queen for being the first player to drop a nova on me. It won't happen again

In summary I was only playing as hard as those around me. I could have played a lot harder (more building). I'm really looking forward to Hall Of Famer, that should be a tough game.

**** Trade Secret.. I don't give these out often ****

I was laying mines everywhere, and I mean everywhere. I had mines in 10 -15% of the universe. This did three things for me.

1. It let me know where people were, and as a result many were podded.
2. If forced players to roam around in ships with hulls smaller than lvl 8. This made it less likely I was going to get attacked by someone. (Although I think Queen worked around this by not repairing her hulls after I attacked and damaged her)
3. It forced players to adjust their style of play to fit mine. Now everyone was in an element that I was comfortable with but that they themselves might not have been.

  Title: Darby's Rangers
Feb 2, 2005 - 12:38 am
Posted By: Ak5intoe

Since the tourney date is rather close to the 60th aniversary (2/1/1944) of the U.S. Ranger battle at Cisterna I thought I'd play in the honor of the fallen 1st and 3rd Ranger Batallions.

"Rangers lead the way" Ranger Creed

"Outnumbered, outgunned, surrounded, confined to a perimeter three hundred yards in diameter, and attacked by armor, the 1st and 3rd Battalions were deluged by a storm of cannon, automatic, and small arms fire. Ranger attempts to escape the encirclement and German attempts to overrun their position were met with unrestrained ferocity on both sides. Two hours later and still continuing to hold on, the Rangers found themselves running low on ammunition.

Growing in strength as the Rangers were being bled dry, the Germans threw the newly arrived 2nd Parachute Lehr Battalion into the fray. Armor, antiaircraft batteries, and artillery in direct fire mode rained destruction down on the entrapped Rangers. Shortly after noon, recognizing that the end was near, the surviving Rangers began disassembling their weapons, burying or scattering key parts, and destroying communications equipment. The last man to speak with Colonel Darby from Cisterna was the sergeants major of the 1st Battalion, Robert Ehalt. He informed Darby that the 1st Battalion commander was wounded, the 3rd Battalion executive officer dead, and German tanks were closing in. Concluding his conversation with "So long Colonel, maybe when it's all over I'll see you again," Ehalt destroyed the radio and continued to fight for a while longer with the few Rangers left before finally surrendering.

Broken into smaller and smaller units of resistance, some Rangers continued to fight it out only to be captured or annihilated in detail. By the end of the day, the 1st and 3rd Ranger Infantry Battalions had ceased to exist, having been completely annihilated. Of the 767 Rangers who reached Cisterna, only six made it back to American lines, the remainder were either killed or captured.

The Ranger's concerns regarding the operation had been realized. The Germans had concentrated considerable strength in Cisterna area of operation in preparation for a German counterattack on 2 February, to include reinforcing elements of the vaunted Hermann Goering Panzer Division on the evening of 29 January. Despite their destruction, though, the Ranger Force extracted a heavy price for their eradication, inflicting over 5,500 German casualties and seriously disrupting the planned German counterattack on the beachhead, thus forcing its execution back by two critical days. This additional forty-eight hours proved to be the difference for the American forces, for the German counterattack failed by only the narrowest of margins. " http://www.johndlock.com/tfwi/wwiieurope.php3

Entry Edited 1 time - Edited on Feb 2, 2005 - 12:45 am

  Title: Newbie survival guide
Jan 11, 2005 - 1:17 am
Posted By: Ak5intoe

You just received your first commission and have trusty space worthy pioneer at your command. Now what?

0. Read the FAQ.

1. Buy and escape pod. If you lose your main ship and you don't have one of these, that's it, the game is over. For your convenience, these can be located in sector 2.

2. Upgrade your pioneer hulls and start trading. As long as you hull level stays below 8 there's no need to worry about mines. However, if you upgrade to 8 or higher, buy as many mine deflectors as you can afford.

3. Once you've built a little capital. Find a secluded spot and settle down. Ideally the sector contains an upgrades port.  Create a planet, base it, and start ferrying colonists to it. As for your sector defenses they only need to deter someone whose slightly bigger than yourself. Focus on your planets. Your goal is to create an income machine so keep the overall tech level to a point where the max credits is practical number.

4. Don't make enemies right off the bat, just watch and observe the interaction of the other players.

5. Don't sleep in your most expensive ship. You're just asking someone to take it from you.

6. Sleep in fed space (sectors 1 - 50) if your average tech level is below 8.  You're safe here.

7. Never perform a planetary transfer without scanning for spies.

8. Use the IGB to collect funds, not a planetary transfer.

9. People can and will follow your warp trail. Never visit your home sector except from sector 1. Otherwise your paving the road for someone to follow.

10. Scan before you attack.

11. Learn how the bounty system works.

12. Debri is a double edged sword. Just because it says you found nothing, doesn't mean you really didn't.

There's still lots to learn, but if you master the above you'll be well on your way to number 1. If you want more detaied info check out some of the other blogs.

  Title: Using the bounty system to your advantage
Jan 8, 2005 - 12:47 am
Posted By: Ak5intoe

After being corrected today that the bounty system is a weapon as well as deterent I thought I'd share some of my ideas for weaponizing the bounty system.

1. Finally, something useful for a team mate. If you have a low ranking teammate you can use him to your advantage (assuming your the team leader). All you do is simply bait someone whose within your range but above your teammate's into attacking your teammate's sector. After the first planet take or so, drop him from your team. Odds are the attacker is working so fast he won't scan again.

2. You could try the above with your teammates ship, but it would be very difficult due to the timing necessary.

3. If you have a sector currently being novaed, have your teammate enter the sector. Then drop him from the team. Same effect as number 1. This is espically evil, because if your teammate is in his own sector then the attacker will receive a bounty for each planet plus the ship!!!

4. If you see a larger player attacking a sector. Try to take one of the planets before he does. If your fast enough, and he isn't watching warp trails, or the screen doesn't update with the rightful owner (as it sometimes does), then you got him. It could be he's already scanning the planet and is backing up to do the attack. In that case he'll never have a chance.

5. Rather than using your teammate as bait, you can use yourself. This works best if you can find someone whom your on the borderline for. Bait them into attacking one of your sectors then have your teammate pull a few (relative) trill, instantly dropping your score.

6. If your really dedicated, you can modify the above secnario by self destructing at the right time. This doesn't make much sense though.

7. Use a non team member bounty player to guard your SG doors. As long as his fighters are high enough the enemy won't be able to run them down. This does has the obvious drawback of keeping you out, but hey, once it's built you don't really need to return anyway.

I'm sure there are others. These are just the ones that came to mind.

I'm also sure that there are numerous spelling and grammitcal errors. English never was my strong point.

  Title: It's the details that count
Dec 27, 2004 - 11:20 pm
Posted By: Ak5intoe

A lot of this game is trial and error. Of course scanning the news groups help to reduce the errors tremendously.

Despite that, I just learned a painful lesson and that's not to forget your realspace sector number that leads to your sector geneisis sectors.

There's nothing like seeing planets get attacked, or people hitting mines, and you can't figure out how the heck to get there.

You spend trillions of dollars on a ship and it's computer can't even remember a simple thing like a sector number, yet it can handle the calculations of faster than light travel.

Must be a mac inside.

  Title: Player Names
Dec 23, 2004 - 1:02 am
Posted By: Ak5intoe

I recently had someone ask me to help them come up with a player name. He wasn't good at picking them out he said. I suppose it is a bit hard to label one's self.

As for my player name it is really the product of an accident. I intended ak5intoe to be my password. So much for all that thought that when into coming up with something cool and original. Oh well, it's starting to grow on me and at least it's original.

Well I suppose that isn't true either. The Black Nova system generated the password for me. I was just too lazy to come up with a new one.

2003-2004 by the Alien Assault Traders developers. All rights reserved.