OneDrive review
Saturday August 16, 2014 05:20:08

I got a free two year subscription with about a hundred gigabytes of Microsoft OneDrive with my Surface Pro 2. If you haven't heard of OneDrive, it's Microsofts way of extending your harddrive by allowing you to store data in their Cloud, similar to Drop Box.

A few weeks back I decided to start using it, even though this meant I had to switch to Microsoft accounts on all my computers, which I had previously objected to due to the creepiness factor.

Initially, OneDrive seemed to “just work.” I'd add a picture or some text file to the OneDrive folder on my desktop, then turn on my Surface to find it's OneDrive folder had the same file there, from the moment I booted up. This solved a major peeve of mine, which is that I must sometimes spend hours syncing files between my Surface and Desktop whenever I switch between the two. OneDrive looked posed to deal with all that crap for me so I wouldn't have to muck with rsync, git, or homegrown tools I'd devised over the years.

But like an abusive lover, OneDrive started out nice and later morphed into a frightening, erratic liar.

The big problem is OneDrive can sometimes take *forever* to copy files around. This kind of defeats the whole “seamless” idea because what I end up having to do is leave both computers on for hours while OneDrive sorts stuff out. I'm aware that this may happen due to network latency but the issues appear unrelated to the size or quantity of files being uploaded and downloaded.

That wouldn't be a problem if it weren't for issue number two: OneDrive is a liar. The interface has this uber-opaque, Fischer Price vibe to it. OneDrive appears in Windows explorer where it looks and behaves like a local drive. But the only options you get are “sync” and “pause syncing.” Oddly enough, it's always that either both are available or both are greyed out. To see the status of what it's doing, you have to open the OneDrive tablet style app, which mostly serves as a clumsy Windows 8 style file browser but contains a small status line at the top of the screen with a single phrase like “one operation in progress…”

This information is often total BS. Many times I'll open up say my Surface for the first time in a week and realize it's missing a directory of newer stuff. So I check the OneDrive tablet style app on the Surface, but all it says is “all files are up to date.” At that point I freak out, thinking maybe OneDrive believes the Surface has a newer version of the data so things will get deleted from the OneDrive servers (note: this has never happened, but I still worry about it all the time). I end up going back to my desktop with a USB drive just to backup the files I need. I'll also click sync on both machines, but get only updates such as “”getting file information…“ for a few minutes followed by ”all files are up to date." Hours later though, just as I'm contemplating abandoning OneDrive entirely, I'll check the Surface and see that the files I'd been fretting over all this time have just appeared with no fanfare.

This latency and abject lying might be ok if I left all my machines on all the time so things were also sync'd when I switched, but one point of “The Cloud” is that these big companies leave their computers on so mere mortals like me don't have to. If I have to keep my Surface and Desktop running for an hour just so a single text file will be available when I switch machines then OneDrive has failed a major part of its mission.

Finally, OneDrive has no way of excluding files. Originally I was storing major amounts of code in OneDrive before I realized it was constantly re-syncing 200mb of compiled object files back and forth. This is a huge deal breaker for storing anything other than simple scripts or compiled tools that don't change.

Even with these faults, OneDrive still does better than my old rsync scripts or Git when it comes to storing infrequently changing large media files, such as photos or drawings. For example, I can stick numerous desktop background images in the OneDrive folder and have them appear on all my machines. The best use case is that I can shove my Sublime installation into OneDrive so I always gets all my plugins on any machine, regardless of where I set them up.

However, due to OneDrive's failings I still end up having to make sure all my local git repos have been pushed to GitHub before I switch and that my old rsync scripts have run, which is a real shame.



Chocolatey- the delicious apt-get-alike for Windows
Sunday February 23, 2014 18:00:58

A long time ago, I realized that despite being somewhat crummy in terms of typical shell features, the Windows command prompt could do everything I usually needed a Unix shell to do. The only issue was the lack of programs and dealing with the horrible way most user guides instruct you to deal with setting environment variables. I decided to use a batch file to set all the environment variables I needed and documented how to do this here. It was a huge improvement over how I'd done things until then, where I'd simply hoped the installers had set (or not set) whichever environment variables I needed and kept a collection of lesser batch files to explicitly change variables when appropriate.

But the experience was still not optimal, and I felt this whenver I switched machines. The problem was all of the tools. So, I decided to create a “tools” directory with actual programs, such as Sublime Text, which I'd want to use on any Windows machine I moved to. This turned out to be a disaster; maintaining all those binary files led to wasted space and confusion. Eventually I settled on storing only a few select things in there, such as the all-important batch file I mention above, as well as a few important things such as my Key Pass install. For everything else I used the native installers which ended up being easier but left me with my original problem.

As any Linux user knows, this state of affairs is less than ideal. It's also fairly specific to Windows. In Linux, there are normally these amazing programs called “package managers” which let you download and install things by entering a single line of text at the command line. OSX has two of them as well- Homebrew and Macports. Windows actually has had package managers too, but the problem is there have been about a half dozen of them which I've seen and none of them contain that many packages. The most important part of a package manager is that it needs to be ubiqitious and have access to everything.

Enter Chocolatey

Yesterday I stumbled across “Chocolatey”, yet another package manager for Windows. I'm ready to say that this is the one all Windows people should be using. It is the first package manager that is good enough to make not using it seem like a mistake.

Why, in my opinion, is Chocolatey better than everything else?

First, it piggy backs off of multiple pre-existing technologies, including traditional Windows exe installers and MSIs. This means many Chocolatey packages are just simple bits of code which silently install pre-existing installers. This means if authors don't want to waste time writing Chocolatey packages in addition to their traditional installers, they don't have to- they (or someone else) just writes a tiny Chocolatey package file that defers to the installer. Adding packages like this is so easy to do it took me just a few hours to write my first one last night.

Second, it piggy backs off NuGet. This is a package manager for .NET language development that has become increasingly popular over the years for distributing libraries with or without code. NuGet recently added support for C and C++ code as well and will probably be the defacto code library manager for Windows in the future (baring any stupid ass decisions by Microsoft to fragment their own ecosystem, which they are fond of doing). What's great about backing Chocolatey with a development focused packaging tool is it makes it more approachable for exisitng developers and also allows for user-facing applications to be created from source, typical to how many Linux packages are distributed.

Third, while many Chocolatey packages do seem to put extra crap on the %PATH% environment variable (mostly because they're based off Windows installers which do the same thing), Chocolatey itself adds a single directory to the path which packages are then invited to install additional batch file redirects to. This helps to keep the %PATH% clean while allowing users to run “cinst” (the chocolatey install program) and have new programs available on their path.

Fourth, Chocolatey has great aesthetics. The name “Chocolatey” comes from a silly joke about how “everyone loves Chocolatey NuGet” which I support as a lover of inane project names that will be passive-aggressively disrespected in a “professional” envrionment (this joke is helped tremendously by the fact that the NuGet logo, when colored brown, looks like a delicious confection). I also love how Chocolatey's output looks- it isn't afraid to use colors- and how pretty it's official website is.

Fifth, installing Chocolatey is very simple- just copy and paste a single line into a command prompt! It's only serious dependency is PowerShell which makes it incompatable with Windows XP, but at this point *no one* should be running XP.

Finally, Chocolatey has already bested its competition by having a ton of packages- 1636 at this moment- and the count is continously growing.

Chocolatey is the future of Windows scripting and development. There is literally [no reason you should not visit it's site and begin using it today.



Keep Code Awake with Very Sleepy
Wednesday January 1, 2014 18:50:11

I've always appreciated quick programs, especially ones that perform well even on ancient or cheap hardware. I feel that most software running today is far slower than it needs to be, which has led to a global waste of hardware resources as everyone compensates by upgrading their gear. So of course I'd like to aspire to write quick code myself.

Most advice I've read on writing efficient code states that measurements are key and should be taken before taking any action at all. Unfortunately, everything I've read fails to mention what tools should be used for measuring code performance or cite products costing thousands of dollars. They often include a snarky comment about how if you're a serious developers you'll recoup your investment anyway. While I've slowly accrued enough hours of experience writing C++ over the years that I wouldn't laugh at myself too hard if I said I was a serious C++ developer, because the majority of work I do is at home in my spare time I just can't justify dropping several grand on code analysis tools.

So I was very happy the other day to discover Very Sleepy, a totally free code profiler that ended up helping me trim nearly 30% off the running time of Macaroni for C++.

Very Sleepy is noninvasive, meaning you don't have to recompile an application to use it (though the app must be compiled with debug symbols). How it works is by suspending the app once each millisecond and recording the stack trace. It then determines how much time is being spent in each function. Here's how I used it to get major performance gains from Macaroni in less than one hour.

Over the past year or so, I've moved from working on Macaroni for C++ in my spare time to actually using it for a game engine. The experience has made me aware of different, more practical issues in Macaroni itself. One thing I've noticed is while run times with Macaroni aren't that bad, they aren't where I'd like them to be either.

A few months back I added a feature to Macaroni which shows the time it's spent running so far next to every line output to the console. That helped me to get some solid numbers on how long projects were taking to parse and build.

Today, I was running a project which Macaroni spent 5.732 seconds simply analyzing and generating code for before it even invoked bjam. This isn't necessarily trivial work, but since Macaroni is not itself a real C++ compiler it's the kind of task I'd ultimately like to see happen in one second or less.

So, I invoked Macaroni as usual but added the “startPrompt” argument, which makes it sit around and wait for a user to press enter. This allows the program to get attached to a debugger. I then opened up Very Sleepy, and found Macaroni on it's list of running processes. I double clicked it, and then raced back to enter something into Macaroni's dummy prompt, so the time spent waiting at the prompt wouldn't skew the results (note that it's also possible to launch a process from Very Sleepy, but I was being lazy - though hopefully this serves as a proof of sorts that even casual usage can yield tangible benefits).

Since Very Sleepy was busy profiling it, Macaroni took longer to run- about 40 seconds or so- but when it stopped I got the following nice window showing all of the function calls in Macaroni and which ones had taken the most time.

One thing that's interesting is that the “% Inclusive” column shows the time spent not just running code in a function, but running all the code that function itself called. Because of this, the highest “% Inclusive” value is for the main method followed by other methods, such as “Macaroni::Environment::ProjectEnvironment::RunCommand,” which are the jumping off points for almost everything that happens in a typical invocation of Macaroni. However, it's still easy to spot functions which you know aren't called that early in the call graph.

The winning stinker of the bunch was “boost::filesystem::canonical” which is used by Macaroni's own Path class (which has different semantics in order to represent C++ source files easily, and which I wrote before I even knew of boost::filesystem… this project has taken so many years) to return an absolute path. As time has gone by, I've peppered the more recently created project / build system in Macaroni with things that need the absolute path, and it turns out the boost::filesystem function underpinning that is relatively expensive.

The fix was to simply cache the absolute path the first time it was computed, which took no time at all. This simple change cut two seconds off the run time, bringing the time until bjam was invoked from 5.732 to 3.874.

In short, Very Sleepy is an incredibly useful tool which makes spotting performance issues extremely simple. I'm grateful to it's authors for writing something so useful and giving it away for free.



Texts- a WYSIWG editor for lovers of plain text
Sunday December 8, 2013 22:30:09


Yesterday I discovered the regretably named Texts, a WYSIWYG text editor that saves to plain text files in the Markdown formatting syntax, which is also used by innumerable sites including Github and StackOverflow.

I once used Microsoft Word for anything that wasn't program code, but as time went on I found myself on machines without Word installed. Buying Word was never worth it to me, yet alternatives such as OpenOffice felt too clumsy to be enjoyable. At some point I decided I'd be able to live using plain text files alone, particularly after I discovered Restructured Text, the primary format syntax used by Python's standard documentation tools. The cool thing about RST files was that they stayed simple text files which could be editted easily in Sublime Text and could live comfortably next to my code and in Github repositories.

However, something always felt off about using Sublime Text to write scripts or stories, probably thanks to the monospaced fonts used for viewing code. While I spent the first five years of my computer enabled life writing stories in Word Perfect and other old school word processors which had nothing but monospaced fonts, at some point using them for creative writing began to feel unnatural. My theory is that as years went by and variable width fonts became more prevelant, my brain began to recognize monospaced fonts as used for reading and writing code only, which caused them to stifle the writing process. While it's possible to use variable width fonts for Sublime Text I couldn't find an easy way to change it on a per file extension basis, meaning I'd have to change it globally and thus ruin the tool's ability to edit code.

The Texts editor on the other hand allows me to write documents with formatting options such as headers and bold text visible, which makes the experience almost as enjoyable as it was on Word. It has the added advantage of saving the files to a format that's friendly to all the programmer tools I already use, such as Git, DiffMerge or Sublime Text. It even supports saving documents in multiple types of Markdown, such as the flavor used by Github.

The only real disadvantage is it supports Markdown instead of Restructured Text- there's a lot of Python documentation that would've been really nice to edit with Texts. Markdown also is a less standardized format than its chief rival. Additionally, Texts is currently a bit rough around the edges- I can't find figure out how to activate the spell checker or exit from full screen mode. However, as its the only real tool I've ever found to scratch this particular itch I still recommend it to anyone who wants the nicities of a WYSIWYG editor but is loathe to give up the independence offered by plain text files.





<---2015-04-25 09:32:55 history 2013-12-07 20:06:00--->



-All material © 2007 Tim Simpson unless otherwise noted-