The more activities you do outside, the more you’ll find yourself looking for a reliable well-rounded knife. I’ve looked at hundreds of knives over the years from many different retailers and varying brands. I’ve consistently been disappointed… until now.
Spyderco, a Colorado company, makes the perfect knife for every outdoor enthusiast; The Spyderco Rescue Assist.
Built to perfection for paramedics, this multipurpose tool deserves a spot in your pack for any activity potentially requiring self rescue. This purpose built knife can cut or “chomp” just about anything, including climbing rope, rappel slings, seat-belts and clothing. It can break glass with its built in retractable carbide tip that protrudes out from the base when compressed and can alert others using the embedded handle whistle. The high friction handle can be securely gripped in any scenario and the base lanyard loop makes for easy carrying on your alpine rack. From canyoneering to alpine backpacking, this rescue knife will always be with me.
Spend your time underwater blowing bubbles? Scuba divers should snag the “salt” version.
“It is a great profession. There is the fascination of watching a figment of the imagination emerge through the aid of science to a plan on paper. Then it moves to realization in stone or metal or energy. Then it brings jobs and homes to men. Then it elevates the standards of living and adds to the comforts of life. That is the engineer’s high privilege.
The great liability of the engineer compared to men of other professions is that his works are out in the open where all can see them. His acts, step by step, are in hard substance. He cannot bury his mistakes in the grave like the doctors. He cannot argue them into thin air or blame the judge like the lawyers. He cannot, like the architects, cover his failures with trees and vines. He cannot, like the politicians, screen his shortcomings by blaming his opponents and hope the people will forget. The engineer simply cannot deny he did it. If his works do not work, he is damned…
On the other hand, unlike the doctor his is not a life among the weak. Unlike the soldier, destruction is not his purpose. Unlike the lawyer, quarrels are not his daily bread. To the engineer falls the job of clothing the bare bones of science with life, comfort, and hope. No doubt as years go by the people forget which engineer did it, even if they ever knew. Or some politician puts his name on it. Or they credit it to some promoter who used other people’s money . . . But the engineer himself looks back at the unending stream of goodness which flows from his successes with satisfactions that few professions may know. And the verdict of his fellow professionals is all the accolade he wants.”
“Every man must decide whether he will walk in the light of creative altruism or in the darkness of destructive selfishness.”
Martin Luther King Jr.
The emulator shipped with ADT is a great tool for both early stage framework development and late stage application development. A large majority of the Android emulator users will only use a small portion of the features for app development. For the developers working on distributed framework development, it is a necessity to be able to sniff emulator network traffic (no Wireshark can’t see the makeshift emulator router). Fortunately, the ADT developers provided two ways to accomplish this.
1) Using the telnet interface (start emulator first)
telnet localhost 5554 network capture start emulator.cap -- Do Something Cool -- network capture stop
2) Using the emulator command line option
emulator -avd myavd -verbose -tcpdump emulator.cap
Afterwords, simply open the cap file with Wireshark. That’s it.
The Android Development Tools (ADT) is a massive project and is very well done. Getting your hands on and compiling the Android Open Source Project (AOSP) is very easy too. So easy, you’ll quickly want to improve your compile performance. An initial compile of AOSP can take about ~46 minutes on an Intel i7 @ 3.4 GHz. Using the compile cache will definitely speed up sequential builds but more can still be done. Sacrificing just a few MB of RAM (~60 MB) for a system temp directory (/tmp) ramdisk can reduce compile time anywhere from ~2%-10% depending on total system throughput (other hardware specs). The C/C++ compiler creates, writes and deletes a temporary file for each source file crunched. Keeping this I/O traffic in RAM offers efficiency gains.
PC Desktop i7 @ 3.4 GHz x 8 w/16 GB RAM and 7200 RPM Drive
Without Ramdisk: ~44 minutes
With Ramdisk: ~41 minutes
Reduction in time playing swords: ~7%
PC Laptop Intel Core 2 Duo CPU T8300 @ 2.4 Gz x 2 w/4 GB RAM and 5600 RPM Drive
Without Ramdisk: 705 minutes
With Ramdisk: 650 minutes
Reduction in time playing swords: ~8%
To setup your /tmp directory to be a ramdisk on Ubuntu systems add the following to your /etc/fstab file and reboot
ramdisk /tmp tmpfs mode=1777,size=2g
There are two quick ways to make sure the ramdisk is working.
1) run the ‘df’ command and confirm /tmp is mounted with the correct size
2) copy a large file to your home directory and again to the /tmp directory and compare speeds
chris@chis-devpc:~/ServerBackups$ time cp 2012.11.04.04.00.MySQL_Backup.sql.gz ~/ real 0m2.657s user 0m0.000s sys 0m0.240s chris@chis-devpc:~/ServerBackups$ time cp 2012.11.04.04.00.MySQL_Backup.sql.gz /tmp real 0m0.224s user 0m0.000s sys 0m0.140s
The file copied above is 208MB. As you can see, the ramdisk was an order of magnitude faster.
WiX is an open source project sponsored by Microsoft that exposes its operating system installer functionality via XML elements. The nuances of this declarative technology and inconsistent syntax have given birth to an entire classification of engineers in the software industry called deployment engineers. These engineers are frequently tasked with packaging and distributing executable binaries for various versions of the Windows platform. All things considered WiX has matured nicely and is becoming quite powerful. That said, it can be a real pain to start using if you’re a novice due to the lack of syntax consistency and plethora of contradictory information on the topic. Not to mention ensuring platform compatibility is nearly impossible given that most people don’t have a copy of every version of Windows ever released… and yes, the installer functionality changed with every version too :-). That said, this post is intended to add to the developer WiX ‘entropy’.
Every book I’ve skimmed through and blog post I’ve read on WiX custom action sequencing is right in ‘theory’ but not always correct in practice… Through trial and error, along with the help of my Chief Architect, we determined that WiX custom action sequencing is fairly arbitrary. To ensure consistent functionality, the action should be schedule after what appears to be an undocumented sequence.
What books and other blogs say to do:
<CustomAction Id="RegisterSomething" Directory="INSTALLDIR"; ExeCommand='regsvr32.exe /s "[INSTALLDIR]something.dll"' Return="check"> </CustomAction> <InstallExecuteSequence> <Custom Action="RegisterSomething" After="InstallFinalize">NOT Installed</Custom> </InstallExecuteSequence>
What you should consider doing instead is:
<InstallExecuteSequence> <Custom Action="RegisterSomething" After="RemoveExistingProducts">NOT Installed</Custom> </InstallExecuteSequence>
Why? Most operations deployment engineers will want to perform during install time will require administrator (“elevated”) privileges. Which means if the Windows user is using UAC it will only run elevated if executed prior to the ‘InstallFinalize’ sequence, not after. Simply changing the original line above from ‘After’ to ‘Before’ will not work consistently either. This is because the sequencing is arbitrary. Meaning that it’s possible for your custom actions to be schedule to run before the ‘InstallExecute’ sequence… because it’s technically ‘Before’ ‘InstallFinalize’ :-). In this case, you’ll be running custom actions on binaries and run times that haven’t been committed to the system yet.