fsck -vf /dev/hdc1 > log
I have now added a detailed no-brainer README for anyone to pick the code up and generate a static site from scratch.1 I’ve also added support for title-less posts, the instruction for which I’ve written up in the README as well. Feel free to hack/fork the code and create your own theme.
The story shared by Rafe inspired me to share a couple of my own.
We were working on an asset integrity assessment project, many years ago, for a super major energy company in the region. The job was to provide a health check of their fixed offshore platforms — about 23 in all.
Our job was to first build non-linear 3D stress models, and use them to check these structures, using the two popular engineering software, SACS and USFOS. While most analytical work could be done with SACS, we could not perform reserve strength analysis. That required USFOS. Given that SACS and USFOS had different formats, and with no converter available, we faced a prospect of rebuilding models for both tools by hand. We would have had to build 23 additional models — if not for an engineer. He single-handedly wrote a successful program to convert a computer model from SACS to USFOS, in three days, translating all model information — node, element, geometry, material, element properties, offsets, eccentricities, loads, load combinations, and end fixities.
One needs to bear in mind that the company had no programmers. Even today, they don’t. Everyone is an engineer—hardwired to use a commercial software. It is also common practice in our industry to discourage programming, because a computer program requires validation and quality assurance. The cost of not doing is a recipe for disaster. He did it anyway, and not only because there wasn’t any other way we could avert loss of time and extra effort, but also because he could. By empowering us, he brought our delivery dates from red in to green.
The other example comes to mind was when I joined this super major a few years later, and started working on the turret-mooring design of its flagship project, FLNG. I was running analysis using Marin’s DYNFLOAT software. DYNFLOAT produced output in binary, and a bunch of output listing files. Because the analysis was done in time-domain, the number of seed runs were numerous, requiring collation, and generating a summary of results to derive statistical mean values. Seeing my helplessness in the time it took me to post-process results, my naval architect colleague rolled her sleeves up, and got down to business. Within a few days, she emerged with a couple of scripts she wrote in Matlab.1 It would pick all my binary output up to generate beautiful results that I could simply scan and report.
I spent the last four years of my life designing mooring systems for large floating vessels — both in shallow and in deepwater. FLNG’s mooring design as it is today is more or less the same design that she and I developed together in 2008-9 before the project went into front-end design, and now into execution. In all these four years, I’ve used this script for thousands of simulations I generated for maturing a number similar projects in the development funnel, saving me hundreds and hundreds of cumulative post-processing hours. I can never be grateful enough for her timely help.
As Rafe says:
Programming empowers you to remove annoyances from your daily life.
Not only does it allow you to test your understanding of how systems work, and force you to think how they ought to work when you code, but also help you automate the things you do not want to spend repetitive time on, and use that saved time instead for something even more rewarding.
She determined the structure of the binary results by investigation—using sparse documentation and by systematically querying the file. She then used the thus determined structure to do the stat and math that would give me a summary of the results I sought. ↩
Programming as a profession is only moderately interesting..You’re much better off using code as your secret weapon in another profession.
While I’m not leaving Tumblr, I am not averse to tinkering with a static site generator script either. Call it Plan B. This for an unlikely event if Tumblr decides to do something I am yet to imagine.1 So, I’ve been trying out Chisel, written by David Zhou.
A few things that jumped at me about Chisel, in spite of the fact that there’s zero documentation, were the following:
I keep a backup of all my posts in Markdown.2 The advantage of this is that I can simply drop these files in a folder, and let Chisel regenerate my entire site in a matter of seconds.
Chisel needs a few packages for it to function. But before they can be installed, one needs pip, a python package installer. On Debian, it can be installed thus:
sudo apt-get install pip-python
On the Mac, you can install pip this way:
sudo easy_install pip
Using pip, install these:
sudo pip install jinja2 markdown
sudo pip install mdx_smartypants PyRSS2Gen
~/site
/posts
/www
Write posts in Markdown and park them in the sub-folder posts , e.g., chiseling.markdown.
All posts require a minimal pre-formatted information for the posts to be parsed into their HTML equivalents by Chisel. Following is the structure of a post:
Post title
m/d/Y
[blank line]
Content here onward.
Date in the second line needs to be input as e.g., 5/14/2012 by default. (Note: Chisel does not support taxonomy, and therefore, there are no fields for categories or tags in the above.)
Download chisel under ~/site folder, so its path would be ~/site/chisel as below:
git clone git://github.com/dz/chisel.git
My fork includes the following that didn’t exist in the original:
There are a few things to set in the single file, chisel.py, which can be edited to suit. Once done, write a post, park the file with .markdown extension under ~/site/posts folder, and then run the following command:
python ~/site/chisel/chisel.py
And the static site will be generated in the www folder. This can then be synced to a web host, either manually, or via a cron job.
Once chisel churns out the posts into html files, the next obvious thing is to serve it. The beauty of generating a site with chisel is that you don’t need mod_rewrite. And once you don’t need it, then running Apache or even nginx feels like an overkill on a home server. Instead here’s what I do. Run the following in a Terminal:
cd ~/site/www
python -m SimpleHTTPServer
Then point my browser to http://localhost:8000. The default port the webserve listens to is 8000. If you’re looking for serving without the port part of the URL (like http://localhost) instead, then you’ll need to run it in sudo, like this:
sudo python -m SimpleHTTPServer 80
Want the terminal free, while leaving the server running until you shutdown? Then append it with an ampersand:
sudo python -m SimpleHTTPServer 80 &
I wrote a tiny snippet in Gedit (under Markdown snippets) to automate the pre-formatted template, and assigned a trigger, ct to this.
$(1:echo $GEDIT_CURRENT_DOCUMENT_NAME)
$(2:date +%m/%d/%Y)
When I open a new .markdown file in Gedit, type ct and hit tab, line one above picks up the name of the file, and line 2, the date—as required.3
I am yet to tinker with its templating engine, Jinja2, but I like what I see. It looks straightforward, and I don’t expect it to vex my learning curve. Plan to work on this over next weekend.
Update: I worked on my layout, and was surprised that it required less than half the markup I thought it would need. Awesome. Here’s a screenshot.
I tend to write directly on my server whenever I use the iPod. This is better than going via the cloud sync. But Vim in its default mode tends to break words, and I need to run this to get non-breaking word wrap:
:set lbr
I avoid setting this permanently in .vimrc as set lbr because that isn’t convenient for writing or editing code.
There are times when I do not like carrying my laptop, and occasionally this becomes my sole rig. But every time I use it, I wonder why I need a computer.1
This log has been on a quote overdrive lately. In my enthusiasm to share, I realized I was crowding my own voice in the process. So, I will be cutting down—moving them instead to my private bookmarking account.
The other thing I want to do is to keep my gripes in check. They bother me more than they bother you, because a sense of helplessness isn’t what I want to share here. Believe me that kind of stuff exists wherever you look.
What I’ve always liked is making this more about positivity and unbridled enthusiasm. One way I measure this is by reading my dated stuff, and see if it makes me feel like it has been a positive contribution overall. Looking at my posts here, by and large, I think I’ve succeeded. That said, a well reasoned long form of writing isn’t possible every day. But I promise I’ll do my best to share, whenever it is I do have something to.
The other aspect of this log is about aesthetics. I spend an insane amount of time on presentation, legibility, words per line, line-height, and colors towards making it a good reading experience. While some think my single column may be too narrow, I think I’ve found a sweet spot that doesn’t stray your focus away when you’re reading. Also, there are no ads, no tracking, no social buttons, nothing to promote, and nobody to influence. This is a labor of love, so if it aims to earn anything, then I hope it’s goodwill.
Add files
git add %|
%| places the cursor at the intended position. If you don’t add individual files, then replace it with the following (to add all files in the folder):
git add .%key:enter%
Commit updates
git commit -a -m '%|.'
Placing the cursor ready to input commit message.
Check status
git status%key:enter%
Push updates to origin
git push -u origin master%key:enter%
From last two, note that you can include keystrokes too. So, the moment I hit ;gp (my trigger for git push command), TextExpander takes my pre-assigned trigger-to-command and pushes it to my (origin) repository—all without requiring the need to press enter manually.
Download from my GitHub repository into TextExpander as Add Group from URL.
Image courtesy: National Geographic, via ASME.
This month marks the centenary of RMS Titanic, the ill-fated ocean liner that hit an iceberg near 41.44N-50.24W and sank—killing over 1,500 of her passengers in the process.
Aside from operational issues (poor sighting, late warning, incorrect instructions to change course upon iceberg sighting, and inadequate time to “hard-a-port” around), the subject of my curiosity has long been on what led to the loss of hull integrity upon collision.
In 2008, The New York Times ran a story titled, “In weak rivets, a possible key to Titanic’s doom”. While this may have been one of the problems, my suspicion—that it wasn’t all of it, and that the key to hull failure was inherently ingrained in mechanical properties of unqualified steel—turned out to be true. Typically, these properties are considered at standard temperature and pressures. Under high temperatures, the molecular grain distribution becomes denser, and vice a versa in cold. In a rectangular plate at low external temperatures, e.g., molecular grain distribution becomes denser at plate’s re-entrant corners, while significantly thinning out at its center—like in magnetism. At a cruising speed of 22knots, her bow plates—brittle due to low temperatures—gave away.
In an article published by the ASME in its Mechanical Engineering magazine this April, titled, “Testing The Titanic’s Steel,” there’s a note by Henry Baumgartner, which suggests it more clearly than ever:
When the Titanic samples were also examined with a scanning electron microscope, the grain structure of the steel was found to be very large; the coarse structure made it easier for cracks to propagate. Rivet holes were cold punched, a method no longer allowed (they must now be drilled), nor were they reamed to remove micro-cracks.
The grain size; the oxygen, sulfur, and phosphorous content of the steel; and the cold punched, unreamed rivet holes were found to have contributed to the breakup of the Titanic, along with the steel’s relatively low ductility at the freezing point of water.
Picture this: you find a good piece of software on github that you want to use. Typically, you’ll click on the download button, and uncompress before using it. After a while, the developer pushes an update. To get this update, you’ll (need to) repeat the above. Here’s a better way:
Let’s assume, just as an example, you’re looking to download the latest version of my WordPress plugin, small-caps. SSH into your host, and run the following under wp-content/plugins folder (This is done just once ever. Updates thereafter do not require to run this):
git clone git://github.com/ckunte/small-caps
A few months later, let’s say I update this plugin.1 To update your server copy to the latest version, here’s what you do: SSH into your host, navigate to wp-content/plugins/small-caps folder, and then run the following:
git pull
Another update in a few months? No problem, just run git pull, and you’d be up to speed with the latest version.
Did you know that you can do all of the above for desktop downloads and updates too? All your computer needs is a copy of git. Whoever said you need to be a developer to use git?
