Settling into OpenID via ClaimID
StackOverflow finally provoked me to stop ignoring OpenID completely. OpenID seems to be the only way to register with the site... I guess that means they don't have to store & maintain login credentials. That seems like a nice bit of delegation.
The hunt was on to set up an OpenID for myself. Afraid of losing my nerd badge I immediately, repeatedly clicked the instructions to run your own server. I didn't really have problems with those until I saw the feature vs. implementation matrix and realized maintaining an OpenID server was an ongoing task of medium effort and low interest.
Apparently plenty of sites are more than happy to give you an OpenID for free. Since it was free my main concern was vanity. I didn't want me.somerandomsite.com. Promoting this blog site was goal #1 so having an id of blogs.foognostic.net was critical. Making that hard was a non-starter.
I surfed through the options and noticed ClaimID. I remember thinking it sounded a little bit like a digital land grab, sort of a squatter's rights deal. Kind of like the flag of the U.S.A. on the moon.
Happily though ClaimID seemed kind of comfortable.
Pros:
- Clear, useful, easy to find documentation
- Easy to get an OpenID at my domain
- Free
- Built and supported by technical types, not excessive biz folks.
- Tips on managing digital identities
Cons / questions
- Why am I supposed to add links to claimid? Why compete with reddit or del.icio.us?
- For Technorati: why can't I sign in with OpenID‽‽ ¿ƃuıssıɯ ı ɯɐ ʇɐɥʍ (thx fliptitle)
Bottom line is that I was able to copy HTML from ClaimID into WordPress and then log into StackOverflow pretty easily. And now I have this OpenID solution in need of login problems. Maybe that will happen more frequently in the future. As a web app developer, I wouldn't mind someone else managing the login credentials.
GNU’ve got to be kidding me — Makefiles?
It's very nerdy but several years ago I really enjoyed getting to learn and use GNU Make. It's best known for compiling and linking C and C++, but it really is a powerful general purpose tool. I'm trying to get back into it and decided to publish that refresher process. Jibe or jive as you will!
First, here is foo.cpp:
#include <iostream>
int main() {
std::cout << "Hello, world" << std::endl;
return 0;
}And here is the Makefile to compile it, link it, and run it:run: foo.cpp
g++ foo.cpp
./a.outThere are three concepts here.- -- this is the target, the goal, what you are trying to do.run
- -- the dependencies of the goal.foo.cpp
- andg++ foo.cpp. Look ma, shell commands! Nothing more, nothing less than the CLI environment many live and breathe../a.out
Just type 'make' and
will follow shortly. This is a pretty bad Makefile though for lots of reasons. Only having one step to compile, link, and run means compiling and linking will happen everytime the Makefile is processed. To fix that, give each stage its own rule:
run: a.out
./a.out
a.out: foo.o
g++ foo.o
foo.o: foo.cpp
g++ -c foo.cpp
Running, linking, and compiling from top to bottom. Make automatically tracks modification dates of dependencies. It will only execute shell commands for objects with modified dependencies. Here is the output from the first time I ran this Makefile.g++ -c foo.cpp g++ foo.o ./a.out Hello, worldWithout changing foo.cpp I immediately ran make again. Here was the output:
./a.out Hello, worldSo that takes care of one glaring problem in the original Makefile. But I just created bar.cpp (it compiles, trust me) and I don't want to add a nearly duplicate rule. That would mean duplicating rules everytime I add a new source file, right?
Make solves that with a page from the Perl playbook; a little punctuation is good, and too much punctuation is awesome! This is perfectly clear, right?
a.out: %.o
g++ $^
%.o: %.cpp
g++ -c $<
'%' is a wildcard character, similar to '+' and '*' in traditional regular expressions. The others I pulled from the documentation on automatic variables, but they refer to the dependencies in the rule (things following the : character).So how'd that go? FAIL.
make: *** No rule to make target %.o', needed bya.out'. Stop.And this is where I remembered gmake has a healthy, happy family of different types of rules. Using '%' in the target of a rule makes it a pattern rule. But the rule for a.out is not a pattern rule, so it looked at %.o as a literal file name. What if I useinstead?
g++ -c bar.cpp
g++ .o
Undefined symbols:
"_main", referenced from:
start in crt1.10.5.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: ** [a.out] Error 1Crap, it did what I said, not what I meant. I said match *.o, which becomes true as soon as one is created. What I wanted was to match ALL the .o files. No getting around that, but at least we can act a little more grown up and use <gasp>variables</gasp>.SRCS = foo.cpp bar.cpp OBJS = foo.o bar.oAnd that works. But now we have another problem! Who wants to update the Makefile everytime a new cpp file is added?? Well, of course there is a solution for this. Half is strange and half is really cool:a.out: $(OBJS) g++ $^
SRCS = $(wildcard *.cpp) OBJS = $(SRCS:.cpp=.o)The strange half is calling a GNU Make function 'wildcard'. That just seems strangely difficult for something reasonably common. Anyways, the cool part was the syntactic sugar to create OBJS by replacing .cpp with .o from $SRCS.
That's about all the refresher I can handle for now. It should be enough to get me going... having done non-trivial cross-platform builds with gmake I know more is possible but I don't need it sitting here at home. At least I know great documentation will be ready when I need it.
C++ versus Java, or references to references versus values of references.
A few years of Java really make it hard to write C++ again. Quick, which language is this?
That works in Java and C++ but for different reasons. It's usually safer in C++.
In Java that code is less safe because it hasn't been tested for null. That is, one of the following already happened:
- Stuff stuff = null;
- Stuff stuff = new Stuff();
- Stuff stuff = Stuff.class.newInstance();
C++ gives you stronger references. For that same line of code, one of these already happened:
- Stuff stuff;
- Stuff *stuff_p = new Stuff(), &stuff = *stuff_p;
- Stuff& f2() { Stuff stuff; return stuff; }
- Thisrefers to an object allocated on the stack. It's there, baby -- as much as anystufforint.float
- Thisrefers to an object successfully allocated in the heap.stuff
- Very bad.destructed the stuff before giving it to you. Just keep compiler warnings on and it will bark "warning: reference to local variable 'stuff' returned"f2
What wasn't shown for C++ was
- Stuff *stuff;
- Stuff *stuff = null;
- Stuff *stuff = new Stuff();
- std::auto_ptr<Stuff> stuff(new Stuff());
- Uninitialized pointer, a.k.a. Runtime Russian Roulette. Unfortunately I couldn't get g++ to whine about this even with.-Wall -Wpedantic -Wextra
- Null pointer, a.k.a. the minimum guarantee of Java.
- Hmm, I don't see a delete any where around here... uh-oh...
- There you go. You've got a smart pointer on the stack to prevent memory leaks, while preserving the expectedsyntax.->
So WHAT? Really now!
Java guarantees that a reference will be initialized, and that it must always be tested for null. C++ warms the hearts of bearded old curmudgeons with more types of references. Each type is useful alone and in sometimes in conjunction (e.g. non-const references to pointers for output parameters). This is useful and important information to know. Draping Object everywhere and automating garbage collection is a lowbrow kludge.
Footnote 1: Groovy's safe navigation operator helps test for null by GOTOing the next safe expression. An interesting idea, and hopefully self-preventative. If I saw code with lots of '?' it would be up for a rewrite sooner rather than later.
Resolving to use C++ in 2009
2009 is almost here and it's time to start thinking about resolutions. Everyone knows that resolutions are honored more in the breach than the observance. Keeping that in mind, here are my presolutions for 2009:
A.) I hereby resolve that 2009 will be the year of C++ for my coding hobby.
... and ...
B.) I resolve to forget about this resolution as soon as my attention span wanes.
I'm justifying this lack of commitment by calling these pre-resolutions or "presolutions" for short. It's only December 2008, I don't see any problems with that.
I haven't used C++ since 2005; back then exceptions and Boost were verboten in the name of cross-platform compatibility. It was a little annoying but understandable; we had to appease C++ compilers from Microsoft, IBM, Sun, GNU, Metrowerks, and others. Hacks appeared all the time... sometimes you just wanted to ignore code rejected by the excellent Comeau online C++ compiler. But actually shipping things means living with warts sometimes.
Back in 2005 I had trouble imagining that Java would survive. I watched the misbegotten offspring of C++ and Visual Basic nearly reimplement CORBA in EJB2 and cackled in glee. Demise was surely imminent.
I've been using Java almost exclusively since 2005. Joke's on me!!
Since then I have been afraid that C++ was fading away into obsolescence. TIOBE says I'm wrong. All those trendy important new programs like "web browsers" not implemented in dynamic languages seem to concur.
Yes, these demonstrate my complete inability to predict trends in my occupational field. Go ahead and snicker, I deserve it. I'm like King Midas in some alternate universe where things I don't touch turn to gold.
So it is with some trepidation that I once again cast my befouling gaze on my fond old friend C++. I can change, things will be different this time! I won't pine over the preprocessor or pointer arithmetic. Honest!
I think I have a lot of catching up to do.
- First, I have to readjust my perspective on coding to include manual memory management, macros, virtual destructors, and avoiding non-const references to temporary objects.
- Next, I need to come up to speed on the standard template library (STL) and resource acquisition as initialization (RAII).
- Not sure how much I need to worry about C++0x.
Quite a lot of work ahead. At least I get to use GNU make again. Seriously. No snickering or eyerolling allowed!
This post is just my attempt to motivate myself. Following posts will (hopefully happen and) be substantial.
How I use GNU Emacs
My last post discussed when and why I started using Emacs many years ago. This post covers how I use it, from the embarrassing beginnings to the hopelessly addicted present. Here are the major stages of Emacs usage in my life:
- It's just an editor: run it every time you want to edit a file.
- Maybe it's a development environment: leave it running all day for editing, compiling, and deploying stuff
- It's the solution, no problem is too great. Bring it on!: In case the temptation occured to you I'm sorry, it's too late. Vi has already been implemented as M-x viper-mode. HHOS.
#1 is the SimpleText/Notepad/vi worldview. After 5 or 6 passes you start to wonder "why isn't Emacs ready IMMEDIATELY?? I just need to add/remove/replace a few characters! Am I using it wrong?" Yes yes yes yes, but don't stop there. After a while you realize it makes more sense to try step #2.
#2 learning enough chord-command-mojo to put text where you want it. Also probably means running one of the internal terminal emulators (shell, eshell, or whatever M-x term is good for??). At the latter part of this stage your caps lock key has become a control key.
#3 is kind of depressing. You have come too far to quit. No one wants to suffer the keyboard shortcut withdrawl it takes to learn a trendy new editor well. It's also depressing to realize you will never use the Dvorak keyboard layout without remapping everything to fit the same keyboard patterns!
Stage three is the scariest stage. It's the all or nothing stage where you decide to use Emacs for as much as possible as often as possible. You pretend like you're not jealous of neat TextMate tricks... and then act all blasé and snooty when someone implements textmate.el.
Slipping for a moment back into why I prefer Emacs
What is textmate.el? Physically it's 234 lines (including comments) of Emacs Lisp. What is it conceptually? A plugin? An add-on? A shared library? A loadable module? No. It's no different than the Elisp that most of Emacs is built with.
I feel like I'm misrepresenting something simple but very important here... not all of Emacs is implemented in Lisp but so much of it is that "plugins" have the same, broad access to the plumbing as core code. Implementing so much of the editor in an interpreted high-level language was questionable when workstations were so much slower. Back when eight megs and constantly swapping was painfully true.
Especially salty old Emacs Lisp (warning: some profanity, and questionable maturity picking names for things 
.
My point here is that the design of Emacs focuses on extensibility and delegates performance worries to Moore's Law. Solid bit of planning there!
Enough of the cheerleading already.
The goal of this rambling logorrhea was to explain how I came to depend on Emacs. Version control integration is cool, sure. And the SQL features sure are slick. What I needed went beyond cobbling together fixes and features.
My problem was disorganization. The brute force mental juggling I tried for so long was A.) reacting badly with an aging brain and B.) an embarrassing stream of forgotten items and prioritization failures. My professional development was stalling.
Since I was suffering from stage 3 addiction to Emacs I looked there first. Hi there org mode! Wow! Using GitHub? OoooOOoooo!
Before org-mode my workarea was basically an altar to post-it notes. This year I have used NONE. I dump things into org-mode (supports internal and external hyperlinks) and refresh my agenda (C-a a) whenever I need a reminder of what to do next. It's quick enough and good enough to be habit forming. Good habits! 
Laziness, or this post is long enough already
I'm not providing screencasts or a detailed HOWTO on using any of my pet modes. Other people have done that better already. I'm going to thank you for reading this far and leave you with a few more fun commands to try:
- M-x woman (surprisingly not offensive. try C-h a woman)
- M-/ (word completion, I do this more often than saving files)
- M-x ido-mode (like a genie for bouncing around open buffers)
- M-x zone (this is a byproduct of extra time!!)
Why and when I started using GNU Emacs
Emacs is one of those polarizing topics among software developers. Maybe it's tripolar: Camp Emacs spars with Camp Vi to the great amusement of Camp Everyone Else. The heckling is especially raucous from Camp Java/C# IDE whose devotees ritually launch The Environment to press the '.' and ';' keys all day.
To make up for that rotten attempt at humor I decided to spend some time explaining why and how I use Emacs. This blog post covers the background, the why and when I switched. The next post will cover how I use/depend on it in my daily workflow.
When MacOS X first came out I was a certified Metrowerks CodeWarrior fanatic. They had the coolest booths at MacWorld, a killer logo, and everyone drooled over the new CWDev tools CD arrived. That powerful, graceful IDE killed Apple's Macintosh Programmers' Workshop (MPW). Now that IDE was a strange beast:
- Ugly, ugly, ugly, and really unintuitive; its icon had binary on it (decimal value 13 I think? 01101?)
- A C compiler with a good sense of humor
- Regular expressions with bizzaro 8-bit characters in the syntax
- Projector, the unlovable source code pseudo-control software
- Locked in a mortal battle with Jasik's Debugger, which
- Was even uglier and less intuitive than Macsbug.
- Was the only game in town for source level debugging of system extensions.
- Had "shortcut" commands which used multiple meta keys at once
- Was so uncool it was trés cool
Metrowerks really ruled the Classic/Carbon Mac development roost for a while. It was really good software. On awesome days I got use MWPro, Jasik, Resorcerer, and Installer VISE.
The fate of these tools was sad but clear when MacOS X arrived. Apple shed everything except its logo. Lots of good reasons to be sure but the process was messy. All the cool tools on my nerd belt could never keep up with the free, bundled tools built with asymmetric knowledge of Darwin and dyld(1).
At this point my current project was written in C++ and built on several platforms. It used imake to build all platforms from a single imakefile... except the Mac build which was a maintenance drag. MacOS X was Unix, right, so all we had to do was port imake to a new platform (arggggggghhhhh). All the imake work in Terminal.app needed a good text editor. XCode wasn't it. CodeWarrior was doomed. I needed something else.
15 seconds with vi was quite enough, thank you.
I remembered this program called Emacs. Sure enough, it was installed. And boy howdy was it weird. Seriously, I had to press control-x and then control-s to save a file???! control-x and control-c to quit?!!! escape-w to paste??? ... for just one brief moment vi started to look better...
... but then Jasik's Debugger came to mind. It used multiple meta keys at once and that was okay, despite them appearing with Ω characters in the menu bar.
That transition to accepting Emacs as probably worth learning happened 5-6 years ago. Emacs is the only program I have used literally almost every work day since then (even using it right now . Initially I just used it to flit between a bunch of files quickly and keep a shell prompt up all day. Just in the last year Emacs has become even much more important as a task organizer and scheduler. But more on that in the next post!
Emacs is just one of the horses for a plethora of courses. I prefer vi for quick edits / wimpy *nix installations, and Eclipse for Java coding. Also, while GNU Emacs is a good distribution Carbon Emacs is not to be missed if you are running a Mac. Grab a copy and have some fun with...
- M-x tetris
- M-x list-colors-display
- M-x animate-birthday-present
- M-x glasses-mode (BestAppliedToCamelCaseText)
- M-x artist-mode, then M-x artist-select-op-spray-can, then click and drag
Task organization, SQL, and VCS chores are the killer apps within Emacs for me. I'll be discussing those in the next blog post. Until then please respond with questions and comments and (good) jokes about Emacs. If by any chance your curiousity was piqued then run, don't walk to the Emacs user community wiki.
