The nice thing about all of this is that I can push a code change to git, and Jenkins can build it, run through all the tests and then deploy to production automatically.

Layout of a pipeline script

Pipeline scripts are written in Groovy, which is a variant of Java. In general, a pipeline script is laid out like this:

node {
    def SOME_CONSTANT = "whatever"
    ...

    stage('some stage name like Build') {
        // Stuff to do as a part of this stage
    }

    stage('another stage') {
        // More stuff
    }

    ...
}

Each stage represents a stage in the pipeline (e.g. building, beta deployment, prod deployment etc.)

Defining some constants

First, a list of constants can be defined that can be used throughout the pipeline so that if the pipeline script gets reused somewhere, only these constants have to be changed. I’m not aware of anything that lets me reuse a pipeline in Jenkins without copying and pasting the code somewhere else so for now I’ll have to live with copying and pasting.

My project uses Maven so I got Jenkins to download its own copy of Maven that it can use to execute builds and have defined it as a constant. The name I’ve given it in the Jenkins Global Tool Configuration is “Maven 3.3.9” exactly. My project also uses Tomcat so there are some Tomcat specific things in there that may or may not be relevant to your use case.

def MAVEN_HOME = tool 'Maven 3.3.9'
    def WORKSPACE = pwd()

    def PROJECT_NAME = "name-of-project"
    def WAR_PATH_RELATIVE = "App/target/${PROJECT_NAME}.war"
    def WAR_PATH_FULL = "${WORKSPACE}/${WAR_PATH_RELATIVE}"
    def TOMCAT_CTX_PATH_BETA = "Tomcat-context-path-for-the-beta-stage"
    def TOMCAT_CTX_PATH_PROD = "Tomcat-context-path-for-the-prod-stage"
    def GIT_REPO_URL = "URL-to-git-repo-ending-in-.git"

Preparation Stage

First, the code has to be retrieved from the repository before it gets built. Jenkins allows storing username/password pairs so that they can be referenced without having to write out the password in plaintext. Jenkins uses a “credential ID” for this.

    stage('Preparation') {
        git branch: "master",
        credentialsId: "credentials-ID-stored-in-Jenkins-that-can-access-the-git-repo",
        url: "${GIT_REPO_URL}"
    }

Build Stage

Next, the code must be built and unit tested. “mvn clean install” will do just that (depending on what you want, you can always put in a different maven goal). The junit command is just there to take the resulting XML that gets generated during the build process and posts a graph of how many tests were run for each build.

    stage('Build') {
        sh "'${MAVEN_HOME}/bin/mvn' clean install"
        junit '**/target/surefire-reports/TEST-*.xml'
    }

Beta Stage

Once the build succeeds, you’ll want to deploy it to a beta environment, so integration tests can happen. The following happens at this stage:

1. Get the right credentials to get permissions to Tomcat
2. Call the deploy method to deploy the war file in Tomcat (more on that later)
3. If the deployment fails for whatever reason, print out the deployment log for debugging and fail the build
4. If the deployment succeeds, run the integration tests (the command to do this may differ based on use case)

    stage('Beta') {
        withCredentials([[$class: 'UsernamePasswordMultiBinding',
            credentialsId: 'credential-id-for-tomcat',
            usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD']]) {
                // Password is available as an env variable, but will be masked 
                // if you try to print it out any which way
                def output = deploy(WAR_PATH_FULL, TOMCAT_CTX_PATH_BETA,
                        env.USERNAME, env.PASSWORD)
                if (output.contains("FAIL - Deployed application at context path " + 
                        "/${TOMCAT_CTX_PATH_BETA} but context failed to start")) {
                    echo "----- Beta deployment log -----"
                    echo output
                    echo "-------------------------------"
                    currentBuild.result = 'FAILURE'
                    error "Beta stage deployment failure"
                }
            }

        echo "Running integration tests"
        sh "'${MAVEN_HOME}/bin/mvn' -Dtest=*IT test"
        junit '**/target/surefire-reports/TEST-*.xml'
    }

The deploy method is what takes care of the actual deployment to Tomcat, which is how the Jenkins build tells Tomcat about the newly built war file. The deploy method is below (be sure to change the server IP and port). Alternatively, I could have built my project as an embedded jar file, but that has a different challenge in figuring out how to get Jenkins to tell the OS to execute the newly built jar file as a particular user.

1. Based on the Tomcat context path, decide whether a beta or production deployment is happening
2. Make a copy of the build war file and add .prod or .beta to the end of it so as to keep the original
3. Set the Spring profile to use on the newly copied war file (more on that later)
4. Call the curl command to do the actual deployment to Tomcat (more on that later)

def deploy(warPathFull, tomcatCtxPath, username, password) {
    def envSuffix = ""
    def isBeta = tomcatCtxPath.contains("beta")
    if (isBeta) {
        envSuffix = "beta"
    } else {
        envSuffix = "prod"
    }
    sh script: "cp ${warPathFull} ${warPathFull}.${envSuffix}" 
    setSpringProfile(warPathFull, isBeta)
    def output = sh script: "curl --upload-file '${warPathFull}.${envSuffix}' " +
            "'http://${username}:${password}@localhost:8081/manager/text/deploy" + 
            "?path=/${tomcatCtxPath}&update=true'", returnStdout: true
    return output
}

In the case of my project, I’m building a single war file that does not have a Spring profile (beta/prod) defined. This means that I have to manually define this before I deploy the app to Tomcat since there are some things that differ between beta and prod like database URL’s. To do this, I wrote a method that opens the war file like a zip (jar/war files are zip files) and adds a line to my application.properties to define a Spring profile.

Admittedly, doing this zip file manipulation seems kind of hacky. Alternatively, I could have defined my build such that I had a separate beta build and a prod build to avoid modifying the zip file, but the drawback is that I’d then have to build my code twice.

def setSpringProfile(warPathFull, isBeta) {
    def zipFileFullPath = warPathFull + "." + (isBeta ? "beta" : "prod")
    def zipIn = new File(zipFileFullPath)
    def zip = new ZipFile(zipIn)
    def zipTemp = File.createTempFile("temp_${System.nanoTime()}", 'zip')
    zipTemp.deleteOnExit()
    def zos = new ZipOutputStream(new FileOutputStream(zipTemp))
    def toModify = "WEB-INF/classes/application.properties"

    for(e in zip.entries()) {
        if(!e.name.equalsIgnoreCase(toModify)) {
            zos.putNextEntry(e)
            zos << zip.getInputStream(e).bytes
        } else {
            zos.putNextEntry(new ZipEntry(toModify))
            zos << zip.getInputStream(e).bytes
            zos << ("\nspring.profiles.active=" + (isBeta ? "beta" : "prod")).bytes
        }
        zos.closeEntry()
    }

    zos.close()
    zipIn.delete()
    zipTemp.renameTo(zipIn)
}

A curl command to Tomcat is what actually does the deployment. To deploy a file to Tomcat, do the following below. This will deploy the war file to Tomcat and instantly run it, thus it will be accessible at the given context path.

curl --upload-file 'path-to-war-file' http://username:password@server-address:port/manager/text/deploy?path=/tomcat-context-path&update=true

Prod Stage

The same kind of stuff happens in the prod stage as in the beta stage with a few exceptions. The following happens at this stage:

1. Get the right credentials to get permissions to Tomcat
2. Call the deploy method to deploy the war file in Tomcat (except this time it is prod)
3. If the deployment fails for whatever reason, print out the deployment log for debugging and roll back the deployment
4. If the deployment succeeds, save the build files, and then the pipeline is finished. Alternatively, smoke tests can be run at this point, but I did not implement this in my project

Rollback is important because if the deployment fails, you don’t want to be stuck with a broken environment. Since build artifacts are saved on successful deployments, these same artifacts can be brought back if future deployments fail. This means they can be redeployed so that the code can be fixed before another deployment happens.

    stage('Prod') {
        withCredentials([[$class: 'UsernamePasswordMultiBinding',
            credentialsId: 'credential-id-for-tomcat',
            usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD']]) {
                // Password is available as an env variable, but will be masked 
                // if you try to print it out any which way
                def output = deploy(WAR_PATH_FULL, TOMCAT_CTX_PATH_PROD, env.USERNAME, env.PASSWORD)
                if (output.contains("FAIL - Deployed application at context path " + 
                        "/${TOMCAT_CTX_PATH_PROD} but context failed to start")) {
                    echo "Prod stage deployment failure, rolling back deployment"
                    echo "----- Prod deployment log -----"
                    echo output
                    echo "-------------------------------"
                    step([$class: 'CopyArtifact',
                            filter: "${WAR_PATH_RELATIVE}",
                            fingerprintArtifacts: true,
                            projectName: "${PROJECT_NAME}",
                            target: "${WAR_PATH_RELATIVE}.rollback"])
                    deploy(WAR_PATH_FULL + ".rollback/" + WAR_PATH_RELATIVE,
                            TOMCAT_CTX_PATH_PROD, env.USERNAME, env.PASSWORD)
                    currentBuild.result = 'FAILURE'
                    error "Prod deployment rolled back"
                } else {
                    archiveArtifacts artifacts: "${WAR_PATH_RELATIVE}*", fingerprint: true
                }
            }
    }

At the end you get to have something like this:

That pretty much sums up the whole Jenkins pipeline that I’ve been using lately for Spring projects!

Every now and then I get this annoying problem in GGTS (Grails/Groovy Tool Suite – Version 3.6.2.RELEASE at the time of this writing), where the IDE just complains about how it can’t resolve a class.  The weird thing is that the file that the IDE is complaining about is in the same package as the class that I’m trying to use.  It built before, and the source hadn’t changed – so clearly this should not be happening.

The Fix

Hitting the Clean button on the Eclipse side (Project -> Clean) seems to make the errors go away.

This apparently has been a problem since June 2010 (forum post reference here), so I’m surprised that it is still an issue in the current version.

Script

I’ve managed to produce a script to disable mouse acceleration (works for me on Ubuntu 14.04).  However, this script needs to be run every time the computer boots because the settings don’t stay.  Here is the script:

#wait for the desktop to settle
sleep 5

#gets the hardware id's of all mice plugged into the system
hardwareIds=$(xinput | grep -i mouse | awk '{print substr($(NF-3),4)}')

#turn off mouse acceleration
for i in $hardwareIds
do
xinput set-prop ${i} 'Device Accel Profile' -1
xinput set-prop ${i} 'Device Accel Velocity Scaling' 1
done

Explanation

The script works by extracting the hardware id’s of the mice that are connected to the system and then applying properties to them that disable mouse acceleration for that device.  The extraction of the mouse hardware id’s are done with this:

#gets the hardware id's of all mice plugged into the system
hardwareIds=$(xinput | grep -i mouse | awk '{print substr($(NF-3),4)}')

Calling xinput in the Terminal will list all the connected input devices, which is grepped (case insensitively) for the word “mouse”, which gives something like this on my machine:

⎜ ↳ Logitech G500s Laser Gaming Mouse id=14 [slave pointer (2)]
⎜ ↳ Logitech G500s Laser Gaming Mouse id=15 [slave pointer (2)]

The call to awk extracts the hardware id from those two lines (14, 15 in the above case) and stores them in an array that is iterated through when setting the mouse properties.

Reference

This is the website that showed me how to disable mouse acceleration to begin with: http://ubuntuforums.org/showthread.php?t=1734400

This specific instance of the problem affects users of the dd-wrt firmware.  In my case, I am using build 24461 of the firmware.  The solution is to run the following commands on the router (either with ssh or telnet):

swconfig dev eth0 set enable_vlan 1
swconfig dev eth0 set apply

I’ve since put this in the startup commands that the router will execute, so these settings will stay even after a router reboot.

For some routers, it might be eth1 instead of eth0.  It depends on which network interface is assigned to the WAN.  This can be check in the router page under Setup > Networking.

Link to forum post: http://www.dd-wrt.com/phpBB2/viewtopic.php?t=152738&postdays=0&postorder=asc&start=0

In a computer, there are various methods of storing information.  Information can be stored in the processor cache, RAM, hard disk, etc.  It can be faster to request information from a storage medium that is smaller.  However, this smaller storage medium cannot fit all the possible information that can be requested.  So the idea is to insert a portion of the data into the faster, smaller medium (the cache) and the rest into the slower, larger medium (main memory).

If a request is made and the data is not available in the faster, smaller medium first, then the data will be read from the slower, larger medium – this is what is known as a cache miss.

Given that all the data cannot possibly live in the cache, there must be a way to minimize the amount of times that the data must be read from the main memory.

Optimal Caching – Farthest-in-Future

The Algorithm

The idea is that there is an algorithm that minimizes the amount of cache misses that occur for a set of requests.  The Farthest-in-Future Algorithm evicts the item in the cache that is not requested until the farthest in the future.  For example, given the following cache with items “a” through “f”.

It is clear that “g” does not exist in the set of cache items and so when “g” is requested, a cache miss will result. An item will be evicted because “g” is not in the cache.  According to the Farthest-in-Future Algorithm, element “f” will be evicted since it is the one that will be used furthest in the future.

Definitions

Cache Miss – Occurs when it is necessary to bring in an item from the main memory into the cache

Schedule – A list that contains, for each, request, which item is brought into the cache, and which item is evicted

Reduced Schedule – a schedule that only brings in an item when there is a request for that item – so a non-reduced schedule would bring an item into the cache outside of a request for that item

Theorem

To be shown:

Farthest-in-Future is the optimal algorithm that minimizes the number of cache misses.

To prove this, let’s say there is a schedule SFF that follows the Farthest-in-Future Algorithm and that there is a schedule optimal S that has a minimum number of cache misses. It can be shown that it is possible to transform S into SFF by performing a series of evictions without increasing the number of cache misses.  Since S^* is already optimal, and the number of cache misses did not increase, then SFF must be optimal.

To perform one transformation, the statement below can be used.  Right now, it isn’t all that clear why this is necessary, but it should become clearer further on.

Let S be a reduced schedule that is the same as SFF for the first j requests, then there is a reduced schedule S’ that is the same as SFF for the first j+1 requests, and incurs no more misses than S

Proof

Let’s say the cache at the start looks like this.  S and SFF have the exact same contents (this is what was defined in the previous section).

Given a schedule S, it can be shown that any request can be made, and the resulting schedule would be equal to the ideal algorithm and does not increase the number of cache misses.  Essentially, we want S = S’ = SFF after a request is made and that the number of cache misses have not increased.  If this can be shown for all different scenarios that items are requested, then Farthest-in-Future is the ideal algorithm.

Case 1: Item Is Already in the Cache

Now let’s say the next item to be requested is item “d”.  It is clear that this item exists in both caches and no evictions are necessary.  Since no evictions are necessary, SFF does not change.  It was specified in a prior section that there is a schedule S’ that equals SFF, which incurs no more misses than S.

Here, S = S’ because no changes had to be made to the cache and there were no cache misses.  After the request for item “d”, S = S’, each with zero cache misses, which is a valid outcome.

Case 2: Item Is Not in the Cache, S and SFF Evict the Same Item

Let’s say the next item to be requested is item “e”.  Neither cache has this item, so an eviction will have to be made.  Let’s also say SFF and S both choose to evict item “a” to make room for “e”.  It was specified in a prior section that there is a schedule S’ that equals SFF, which incurs no more misses than S.

Here S = S’ because S and SFF both evicted the same item.  Both S and S’ each have one cache miss (no increase relative to one another), which is a valid outcome.

Case 3: Item Is Not in the Cache, S and SFF Each Evict A Different Item

This is where the proof can become more confusing (as if it isn’t already).  Let’s say the next item to be requested is “e”.  Let’s also say that the ideal algorithm, SFF, evicts “a” and S evicts “b”. It was specified in a prior section that there is a schedule S’ that equals SFF, which incurs no more misses than S. This means that in order to get S’ = SFF, S’ should evict “a” in order to match with SFF.

Here, S does not agree with S’ = SFF.  Essentially, these two schedules behave the same, so long as future requests do not request items “a” or “b”.  This shows that there is a schedule S’ that equals SFF, but it is not known whether or not S’ has no more cache misses than S, since “a” or “b” can be requested in the future, which can determine whether S or S’ has more cache misses.  From this point onward, S and S’ behave the same until one of the following happens:

Case 3a: Item Is in SFF, But Not S; S Evicts “a”

Let’s say eventually item “b” gets requested.  In this case, S’ and SFF do not need to change.  All S has to do is evict “a” to make room for “b”.  In this case, S has two total cache misses (from request “e” and “b”), while SFF and S’ each have only one cache miss, thus fulfilling the cache miss requirement.

Case 3b: Item Is Neither in SFF Nor S

Let’s say eventually item “f” gets requested.  S’, SFF, and S all need to make an eviction. S’ and SFF can evict “b” to make room for “f”, and S can evict “a” to make room for “f”.  In this case, each schedule as two cache misses, thus fulfilling the cache miss requirement.

Case 3c: Item Is in SFF, But Not S; S Evicts Item Not Equal to “a”

Let’s say eventually item “b” gets requested and S evicts an item that isn’t “a”, say “c”.  Now, SFF and S’ both already have “b” in the cache.  In order to synchronize S and S’ to make them comparable to see how many cache misses each have, S’ and SFF will evict “c” to make room for “a”.

Since “a” is being brought into the cache without a request for “a”, this makes S’ and SFF no longer a reduced schedule.  However, the proof calls for S’ and SFF being a reduced schedule.  Fortunately, it is possible to transform an unreduced schedule into a reduced one.  In this case, each schedule has two cache misses, thus fulfilling the cache miss requirement.

Case 3d: Item Is Not in SFF, But in S

The only item that is in S and not SFF is item “a”.  SFF had evicted it initially at the beginning of Case 3.  Since SFF had evicted it, it must have been the item that would be requested furthest into the future.  Therefore, it is not possible for item “a” to be requested before other items.

After going through all possible eviction decisions that the schedules can do, it was shown that for each scenario, there was indeed a schedule S’ = SFF, where the cache misses incurred in S’ no more than S.

These two keys toggle the full-width (double-byte), and the half-width (single-byte”) character sets when typing with the Chinese IME.  Full-width characters look like “ｔｈｉｓ “ while half-width is what people are normally used to.  The default key combinations are easy to press by accident in situations such as capitalizing a title.  Therefore, it is beneficial to remove this hotkey.

Solution

Because changing the key settings manually through Windows does not work, one must go through the registry.  The following fix applies to the current user that is logged in.  Apply the following registry keys and then restart the computer.

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Control Panel\Input Method\Hot Keys]

[HKEY_CURRENT_USER\Control Panel\Input Method\Hot Keys\00000010]
“Virtual Key”=hex:ff,00,00,00
“Key Modifiers”=hex:00,c0,00,00
“Target IME”=hex:00,00,00,00

[HKEY_CURRENT_USER\Control Panel\Input Method\Hot Keys\00000011]
“Virtual Key”=hex:ff,00,00,00
“Key Modifiers”=hex:00,c0,00,00
“Target IME”=hex:00,00,00,00

[HKEY_CURRENT_USER\Control Panel\Input Method\Hot Keys\00000012]
“Virtual Key”=hex:ff,00,00,00
“Key Modifiers”=hex:00,c0,00,00
“Target IME”=hex:00,00,00,00

[HKEY_CURRENT_USER\Control Panel\Input Method\Hot Keys\00000070]
“Virtual Key”=hex:ff,00,00,00
“Key Modifiers”=hex:00,c0,00,00
“Target IME”=hex:00,00,00,00

[HKEY_CURRENT_USER\Control Panel\Input Method\Hot Keys\00000071]
“Virtual Key”=hex:ff,00,00,00
“Key Modifiers”=hex:00,c0,00,00
“Target IME”=hex:00,00,00,00

[HKEY_CURRENT_USER\Control Panel\Input Method\Hot Keys\00000072]
“Virtual Key”=hex:ff,00,00,00
“Key Modifiers”=hex:00,c0,00,00
“Target IME”=hex:00,00,00,00

[HKEY_CURRENT_USER\Control Panel\Input Method\Hot Keys\00000201]
“Virtual Key”=hex:ff,00,00,00
“Key Modifiers”=hex:00,c0,00,00
“Target IME”=hex:00,00,00,00

[HKEY_CURRENT_USER\Control Panel\Input Method\Hot Keys\00000202]
“Virtual Key”=hex:ff,00,00,00
“Key Modifiers”=hex:00,c0,00,00
“Target IME”=hex:00,00,00,00

[HKEY_CURRENT_USER\Control Panel\Input Method\Hot Keys\00000203]
“Virtual Key”=hex:ff,00,00,00
“Key Modifiers”=hex:00,c0,00,00
“Target IME”=hex:00,00,00,00

In the registry, one can also navigate to “HKEY_CURRENT_USERControl PanelInput MethodHot Keys” and see a list of folders with names that have eight numbers in them with leading zeroes.  Each folder here represents a particular hotkey related to an IME.  Clicking on one of these folders will show data for these keys.

Setting “Key Modifiers” to “00 c0 00 00” removes the use of the Ctrl and Alt key for the hotkey.
Setting “Virtual Key” to “ff 00 00 00” sets the key to nothing.
The key “Target IME” can be left as is.

In the case of the “Shift+Space” hotkey, “Shift” is the key modifier and “Space” is the virtual key.

It is unclear which folder corresponds to the key that toggles the character shape, therefore this fix is a blanket approach.

If the Above Still Fails

Try combining the fix with an installation of Microsoft Office IME 2010, which can be downloaded here: http://www.microsoft.com/downloads/zh-tw/details.aspx?FamilyID=60984ecd-9575-411a-bd38-2294f17c4131&displaylang=zh-tw.  Despite the name, it does not require Microsoft Office to be installed. After installing, apply the registry keys and restart.

The following solution is proposed:

Use Microsoft AppLocale

Microsoft AppLocale allows running a program using a particular language without changing the Windows language setting.  That means, one can change between multiple languages on-the-fly for each program.

According to Microsoft:

Unicode based platforms, such as Windows XP, emulate the language environment required to run non-Unicode applications by internally converting application’s non-Unicode text data to Unicode using a system-wide variable commonly called the system local (or language for non-Unicode applications). The language of the non-Unicode applications should be of the same script or family as the one defined by the system locale. Failing to meet this condition results in display of garbage characters in the UI of the application.

Download link

Once downloaded, install and run it.  Follow the instructions and choose what program that is to be run at the wanted language.  If the correct language was chosen, the application should show the correct characters.

• Intel Core i3-370M Processor (2.4 GHz)
• Nvidia G310M Graphics Engine with 1 GB DDR3 Dedicated VRAM and Optimus Technology
• 4 GB of DDR3 1066MHz DRAM (2 GB x 2 slots)
• Intel Wireless 802.11 b/g/n + WiDi
• 500 GB Hard Drive (5400 RPM)
• Windows 7 Home Premium (64 bit) Operating System (which I upgraded to Pro)
• 13.3-Inch HD (1366×768) LED Display
• HDMI Port
• USB 3.0 port
• Bluetooth
• 8 cell 5600 mAh battery

The one thing it doesn’t have that I realized just now is that the computer doesn’t have an optical drive. I didn’t know that before. I guess I assumed that all computers except for netbooks have them. It’s not really a big deal though.Since my laptop kind of died on me earlier, there weren’t many things I could do to solve the problem. I pretty much only had three options: get my laptop repaired, buy/borrow a monitor for the duration of my stay, or buy a new laptop.

Repairing my laptop was definitely the first thing I tried. I researched on how to fix it, but I couldn’t even get the screws out to even peek at the insides. Right now, I still think that the problem inside the computer is just a loose connection. Unfortunately, I can’t confirm that. I could let Dell fix the computer, but my warranty expired a long time ago. I also bought the computer from Canada and would have to go through lots of red tape just to get it repaired by Dell Europe.

The next thing I tried was to find someone who had an extra monitor I could borrow. Since all my friends in Germany are all interns or thesis students, they all had only a laptop and not an extra display. Although, I did manage to borrow one for like a week until I had to return it. I could have bought a new monitor, but then it would have been really been difficult to bring home a 20 something inch screen (if I’m buying a monitor to keep then I wouldn’t buy anything smaller). I didn’t feel like buying a cheap one and just leaving it behind when I leave Germany either.

In the end, I ended up buying a new laptop (with much financial assistance from my parents). I figure my old laptop is getting old anyways (2007), and for the past year and a half it had been failing to keep up with my intense computer usage habits. When I return to Vancouver, I’ll get this laptop repaired and then my parents could use it (or my brother if he decides that he needs to bring a laptop somewhere).

After almost four years of using my Inspiron 1520, its age finally caught up with it and its light literally went out.  The backlight refuses to turn on now.  I came back from Berlin last Monday and found my computer in this state.  I left it off during that time too.  During this time, I had trouble doing any blogging and uploading any photos.

Google told me that the problem lay with either a loose connection, the inverter or the lamp.  I tried to check this out myself and open the computer case, but the screws refused to budge.  People online somehow got theirs open, but I couldn’t.

Unfortunately, my warranty expired so I’d have to pay to get this computer fixed.  I looked at my options on the Dell site and the North American Dell Support refused to help me and kept referring me to the European side even though I bought my computer in Canada (I really don’t know what these guys at the call centers are doing).  After about three calls to the support line, I finally found someone helpful and she told me that I had to change my laptop registration such that it showed a European location before I could get it fixed.  An alternative option would have been to send the computer back to Canada to get it fixed.

What I did instead was just buy a new laptop.  My laptop is already super old and already can’t really keep up with my tasks anyway, so I suppose it’s time for an upgrade.  What surprised me was that laptops in Germany (from their Best Buy/Future Shop equivalents anyway) cost so much more than in North America.  In fact, it was cheaper for me to buy my computer in Canada and get my parents to ship it to me rather than buying it locally.  I’m sure there are cheaper places, but I don’t exactly know how to look through all these German websites.  Another added advantage in buying from Canada is that I’d have a computer with the US Keyboard layout rather than the German one.  And in the future when my laptop needs repairs, it’ll be easy.

In the meantime, I’m using a 17 inch LCD screen that I borrowed from a friend.  This will suffice until my new computer arrives.  No more shining a lamp at my computer screen and squinting my eyes to see the screen anymore.  I also don’t need to be using my phone to go on the internet at home either.

For more information about the program, see the original post about it.

Requires Java to be installed.  Link for that here.

SourceForge Page: http://sourceforge.net/projects/aa40battlecalc/

Download: http://sourceforge.net/projects/aa40battlecalc/files/Battle%20Calculator%20Binary/v1.0/BattleCalculator-v1.0.jar/download

Source Code: http://sourceforge.net/projects/aa40battlecalc/files/Battle%20Calculator%20Source/v1.0/src-v1.0.zip/download