What code did you write today?

[Shaun]

My recent coding is a bash script using s3cmd to sync the CycleChat server with an Amazon S3 bucket; which will be fired-off by cron in the early hours of every Sunday morning (the quietest time on the server).

It's taken some doing as certain files in /proc and /var/lib/elasticsearch crash and halt the sync and the --exclude parameter doesn't work for some strange reason, but after some experimenting I managed to exclude them by pushing separate sync's only for the directories I do want to backup within /var

The longest part has been seeding the initial backup - 36 hours and still going. CycleChat's /home directory comes in at 27GB with nearly half a million files, and that's without the SQL database (another 6.7GB) or the rest of the server contents.

 

[slowmotion]

I dragged a BBC model B, a Technomatic disc drive, and a Texan monitor out of a dusty place at work yesterday. I think it was last used in anger in about 1986. Somebody wanted some data on thirty year old floppies put into a more friendly contemporary format. It was blooming odd to see the start-up screen , complete with the 16k memory message after such a long time. I tried to write a few lines of code to make the computer beep a bit (anybody remember VDU7??????), with limited results.

Loads of fun though.

 

[martint235]

Being a software engineer is frustrating, sometimes. I spent over 11 hours yesterday, with no lunch break, trying to analyse and reproduce the symptoms of a very random software problem, and had no luck. One of my colleagues also tried, with no results, either. Given that he's based in Singapore and I'm in Melbourne, we had to talk via MS Communicator, which made things a bit inconvenient. I think this sums up my feelings quite well:

Ah poorly written, badly commented code always comes back to bite you eventually.....

 

[ianrauk]

My recent coding is a bash script using s3cmd to sync the CycleChat server with an Amazon S3 bucket; which will be fired-off by cron in the early hours of every Sunday morning (the quietest time on the server).

It's taken some doing as certain files in /proc and /var/lib/elasticsearch crash and halt the sync and the --exclude parameter doesn't work for some strange reason, but after some experimenting I managed to exclude them by pushing separate sync's only for the directories I do want to backup within /var

The longest part has been seeding the initial backup - 36 hours and still going. CycleChat's /home directory comes in at 27GB with nearly half a million files, and that's without the SQL database (another 6.7GB) or the rest of the server contents.

I like Ready salted crisps.. do you like crisps?
Now all that just went woooooooooooooooosh right over my head.

 

[Shut Up Legs]

Ah poorly written, badly commented code always comes back to bite you eventually.....

Yes, especially when you're working with over 1 million lines of code, written and updated by who-knows how many software engineers. We have a pretty good code-review system, but with that much code, it gets hard to find bugs sometimes.

 

[Shut Up Legs]

I like Ready salted crisps.. do you like crisps?
Now all that just went woooooooooooooooosh right over my head.

I have cheese & onion crisps just waiting for after dinner. My commute home has given me a big appetite.

 

[martint235]

I like Ready salted crisps.. do you like crisps?
Now all that just went woooooooooooooooosh right over my head.

Yeah well you'd never heard of 7Zip until yesterday.

 

[Shaun]

I like Ready salted crisps.. do you like crisps?
Now all that just went woooooooooooooooosh right over my head.

I did a backup.

 

[ianrauk]

Yeah well you'd never heard of 7Zip until yesterday.

This is true..
And you never heard of WeTransfer either.

 

[ianrauk]

I did a backup.

Language I understand

 

[Shut Up Legs]

The good: I fixed a bug in my cycling logging application, a roughly 25,000-line Java application I wrote a few years ago to log all my cycling trips, and import TCX and FIT files.
The bad: I'm trying to get SportTracks working in Linux using WINE (because I still use it, even though I wrote the above application), but it's a bit right now.

 

[Shut Up Legs]

I fixed another bug in my cycling logging application, and it didn't take very long, either. Must be all the practice I get at work, I guess. I then downloaded and installed the CLOC (count lines of code) utility, and ran it on the application's source code. It informed me that the application has almost 33,000 lines of code.

 

[marknotgeorge]

I've been connecting a Wiimote to my Raspberry Pi 2. My bit of hair-shirtedness is using C# instead of Python, and all the available code is several years old and either Windows-specific or bare-bones wrappers on C libraries. So I'm doing it properly, all object-oriented and with interfaces for the C library wrapping code to allow for unit testing. So far, I've managed to connect to a Wiimote and activate the rumble motor.

I appear to have created a vibrator.

 

[Shut Up Legs]

I just got a pair of Linux shell scripts working, that save my RTC (Real-Time Clock) wake time before shutdown or reboot, and restore it on bootup.

This was because I found that the RTC wake time gets cleared when you shutdown or reboot, and I rely on the RTC wake time being set for my weekly backup script to run on Sunday nights, because if the PC didn't wake up, then the script won't be able to run. I still need to be able to reboot the PC occasionally, though, so had to find a way to restore the RTC wake time on bootup. It works fine now, though.

Yesterday, I continued work on my cycling trip logging application, a roughly 30,000 line Java application I've been developing for years now. My most recent change is graphing! I'm working on the code to draw various types of graphs (line, bar, scatter), which will allow me to plot various cycling trip related info, e.g. distance done per month, average speed for selected trips, etc. It will be a while before I can see any graphs, though, as graphics tends to be fairly complex, particularly if you want it to be efficient and not make your application really sluggish. It's coming along nicely, though.

 

[Shut Up Legs]

More Linux shell-scripting today. I wrote a script to log the transitions between the different Linux run-levels, and also any power state changes.

For the run-level changes, the script is called from a 1-line script in /etc/init.d, and for the power state changes, the same script is called from a 1-line script in /etc/pm/sleep.d . In both cases, the script has 1 argument, either a run-level (0 to 6) or the name of a power state change (resume, thaw, suspend, suspend_hybrid, or hibernate).

The script is fairly simple at the moment, and just appends the current time and the event to a log file. I plan to make it smarter, though, as I wrote it because I wanted to find a way to detect power outages, which is something a PC typically doesn't log, unless you've invested in a UPS of course, but I don't have one of those.

Detecting a power outage is an interesting problem. You can of course have the script check recent run-level or power state events in the above-mentioned log file, and e.g. if it detects a transition to run-level 2 (aka 'single-user mode' or 'desktop-running-mode'), even if there was a matching shutdown event (run-level 0) or restart (run-level 6), how can we tell if the power was lost between these 2 events? I haven't worked that one out, yet. It probably doesn't matter anyway, because if the power's lost while the PC is shutdown, it won't harm the PC: it would just be nice to record it somehow.

I can detect a power loss during suspend to RAM, however. The script will log a 'suspend' power state, and if the next event is a transition to run-level 2, then the power was lost between these 2 events, because if the power had stayed up during the suspend period, the 'suspend' event in the log file would be followed by a 'resume' event. Testing this is problematic, however: I'm not keen on testing it by cutting the power to the PC, as this can possibly cause problems.
Another way to detect suspend to RAM followed by resume is to write a file to a directory mounted on a RAM partition (e.g. /run/user is a common directory setup this way). Then if the power stayed on during the suspend period, the file will still exist in /run/user after the resume, otherwise it will be gone.

Another clear indicator of a power loss, of course, is a transition to run level 2 without any previous matching transition to run levels 0 or 6, which basically means the PC didn't do a normal shutdown.