sizeof(uint32t)

Does it get much worse than this

noreply@blogger.com (Unknown) — Wed, 16 Feb 2022 05:56:00 +0000

October 26, 2021: The cultural elites driving this lock down will be caught off guard as they were caught off guard by he-who-shall-not-be-named. As with anyone losing power, they will try to increase their grip. It will be bad.

So if the protests can be quashed without losing moral authority, and maintaining power, that gives the elite the confirmation that they do indeed have very strong control over much of the world economy. And as said in a previous post, they are very much happy with the fact that they get along well together.

It seems they have lost the moral authority now. The federal government of Canada is being openly mocked worldwide by private news media. Oligopoly/state-owned news media is carrying water for the aforementioned reason, that the self-styled elites who run things behind closed doors are very invested in the outcome in a major Western country. After Canada, USA is next. There is an intuitive understanding of this which is why so many in the US are invested in what is happening in Canada.

But in the end, the people will refuse to participate and will develop the leverage needed to add the right checks and balances to a system that is sorely lacking them. I doubt it will be violent.

So far so good.

There is a rumor that the PM of Canada attempted to get the military involved and they said no. It is a rumor, but...

Will the enforcers support the leaders if they require violence?

I'm not so sure.

There are also rumors that certain police forces are siding with protesters. I do not know how true this is.

A famous psychologist has referred to the current PM as a teenage actor. If true, this means that his reactions are unpredictable and will be inward focused. A dangerous combination.

I'd be worried, if it didn't seem that the federal government of Canada is grasping at straws to hold onto power (the "It will be bad" part of things) and the enforcers are perhaps refusing to intervene.

This isn't an attempt to consolidate power. This is an attempt to hold onto the last bit of power they have left. It looks the same, but has wildly different outcomes.

Excess performance and outcome independence

noreply@blogger.com (Unknown) — Fri, 11 Feb 2022 13:03:00 +0000

Outperforming can be relative.

For example, someone raised in poverty achieves excess performance simply by moving to the middle class, having a retirement fund and a successful marriage.

In software development, excess performance falls under multiple potential categories:

Design
Implementation
Management

In business, excess performance is obvious assuming no shenanigans.

In many cases, it may be hard to quantify, but you know what it looks like when you see it because it stands out.

Many who outperform in various situations in life were coached into it as children and their "excess performance" actually does not exceed what other similar children would achieve. For example, if one went to private schools, and their friends went to private schools and they all have similar careers, one did not out perform anyone.

In that case, it is more likely that the parents are those who outperformed, not the children, depending on the parents' peer group.

What is excess performance as an adult that is independent of your background?

Learn a new skill, and make more money doing it.

Career progression can be a form of excess performance. For example transitioning from individual contributor to CTO of a non-trivial company over a period of time.
Money is just a simple way to keep score. One might also take up painting and even selling 3-5K of paintings per year could be out performance (not that I would know!)

Fix a long standing physical or mental health problem/breaking long standing habits

Aside from the obvious, this can be things as simple as choosing the type of people you wish to be around.

There are surely more examples, but successfully accomplishing either of those requires so much time that it is almost impossible to achieve as an adult.

You need to make the time.

While aiming for excess performance is something everyone wants to do, in practical terms it is actually quite difficult and ugly. It's easier to just sit around and retain the status quo (there is nothing wrong with this, life satisfaction is very important.)

But if someone is trying to exceed their station by one or two standard deviations, it requires an unrelenting focus.

Focusing on one thing will potentially mean letting other less important things fall off.

Do this consciously.

If you achieve the excess performance that you sought, you know the things you lost were worth it. If you did not achieve the excess performance, and lost the less important things as well, you were already prepared.

By making this active decision, you are now outcome independent.

I am debating whether to talk in less vague terms about this, but perhaps another day.

What's next (and an apology)

noreply@blogger.com (Unknown) — Sat, 29 Jan 2022 14:00:00 +0000

I apologize for making this blog political/personal recently. I know this is/was a tech blog and trust me, I have a ton of very cool tech stuff to write about (see here for some stuff I've been working on) and I will write about it again.

While Canada, the land mass is "rich", the civilization is stagnating and part of this is an overreaching government bureaucracy that infects every aspect of our lives and makes too many people dependent through its largesse. Roughly 10% of the population is directly employed by the government which doesn't sound too bad, yet government spending is 50% of GDP. Out of the remaining 50%, half is housing related and commodity extraction. Note that I understand government spending can be beneficial to the economy. At these levels and the sectors, it is purely a jobs program. Housing prices in Canada are soon to be the biggest export. No, they are not going to do anything about it. So in effect, perhaps 60% of GDP is directly dependent on the government for growth.

This situation is not at all unique in the world. There are a cluster of currently stable countries with similar nominal GDP which share a similar economic and roughly similar government structure. Included in this list are France, Belgium, Sweden, Germany, Netherlands, UK, and Spain.

That could be why it was so easy for such countries to "shut down" and remain shut down as government is a large component of the economy and who is going to complain about being paid to stay home while their homes appreciate another 40%? Other countries could literally not afford to stay closed, and did not.

Through the pandemic response and economic policies, it's relatively easy to see that such countries are fundamentally in decline and the pandemic is being used as an excuse to paper over it. See The Changing World Order by Ray Dalio for a great exposition. I also recommend his debt crises book. The US is apparently faring better in pockets, for example Florida and Texas are largely open without disproportionately negative pandemic outcomes while other states continue to occasionally "lock down". China's "zero COVID" policy likely never worked, but we'll never know the truth.

I like to consider human civilization as an organism. If you've ever watched traffic going in and out of a city over a period of a day, it's like an animal breathing and can be mesmerizing. As a result, I see the Canadian trucker protest, sizable or not, as a blister that has popped. Or a tumour that will grow. Which one it is, I don't know. Insert your favourite analogy here.

That being said.

What is happening?

Justin Trudeau has absconded and left Ottawa under the guise of quarantine. He is basically going to wait out the protests and is no doubt planning with other leaders on how to deal with the problem perhaps without having to give it the dignity of a formal response.

As in the previous couple of posts, I said they will try and increase their grip. Nova Scotia recently is attempting to outlaw this specific form of protest. Expect Ontario/Ottawa to follow suit.

The key bit of this kind of legislation is they are making donating to the cause illegal as well. And given the Canadian Charter of Rights and Freedoms isn't anything but a polite suggestion, it is likely to be upheld on appeal.

Why truckers?

I suspect this is mostly because truckers represent many productive and necessary parts of the economy, but also because they are mostly independent even indirectly, from the wealth of government. Side note: one of the most wealthy people I know runs trucking companies in multiple countries. It really is a purely capitalistic endeavour for the most part. The second most wealthy person I know has his huge business tied 80% to government.

What is immediately next?

The logical conclusion of this is that the powers that be are setting the stage for violence but will initially attempt to extinguish whatever vigour exists through lack of media coverage and perhaps also preventing the trucks from entering Ottawa.

Trudeau has already signalled the basics of the government approach. They will wait it out and set the stage to apply force if needed. I am not sure how well organized this protest is, and how long they can hold out but this appears to be the approach.

The truckers on their end cannot leave Ottawa until mandates are lifted wholesale or they are forced out. The only way the truckers can remain in protest mode is if they have supplies going to the front lines. This is only possible if people continue to donate to the cause.

The truckers have to be prepared to become VERY uncomfortable.

When faced with protests, governments have 3 major responses:

Accede/negotiate
Ignore
Respond with violence

If the legislative response from Nova Scotia is to be enacted, and be replicated across the country, particularly in Ontario, then the state has chosen to set the stage for (3) as laws are enforced by violence. Hence why they are seeking to make funding the protest illegal.

Being in the cross hairs of the government enforcers is a very expensive proposition in all Western democracies even if you have done nothing wrong. Anyone donating to the cause will think thrice.

Therefore, laws preventing funding of the protest cut off the most important input into the effectiveness of a long term sit in type protest.

There is a very large chance that the funding platforms will say "well, nothing we can do about it, the government made it illegal" and cancel all funding raised.

There is a very small chance that the organizers will encourage people to donate via Monero which is a privacy preserving cryptocurrency, but it is a black swan that will change the entire circumstances of the protest. The government may make such crypto illegal as a result.

In summary:

The government has chosen violence, it just hasn't applied it yet
The truckers funding is likely to be cut off
Small chance of the use of the Monero cryptocurrency to counter funding issues

What could the government do?

It isn't talked about enough but the UK basically said they are done with the authoritarian approach and from my friends in the UK, things are back to normal and have been for a long, long time. See here for more. No vaccination passport, etc.

The Canadian government could follow suit. Unlikely, but possible.

What is "big picture" next?

Many are watching similar protests worldwide to see what comes of them. Do governments blink, or does authoritarian policy win? If the latter, that sets the stage for the much desired "one world" government, which more or less already exists.

Central banks move together. Government policy moves together, usually led by the US but recently Chinese style policy is making its way to world governments. For example, recently the President of the CCP more or less threatened further supply chain issues if the Federal reserve of the US raised interest rates. They are already cooperating for the most part and anyone who can move between the worlds with ease can control it.

So if the protests can be quashed without losing moral authority, and maintaining power, that gives the elite the confirmation that they do indeed have very strong control over much of the world economy. And as said in a previous post, they are very much happy with the fact that they get along well together.

Pop quiz

The following is a chart of Canadian government spending as a percentage of GDP. Guess when Canada went off the gold standard.

No, it wasn't 1970. Yep, it's the first bump.

Why? Because government needed to fund itself without constraints. It's hard to know what the outcome is for situations like this, but history is probably a better guide than intuition. So the thought experiment to perform is as simple as: "What civilization am I aware of that has lasted for hundreds of years with a government that takes up more than 50% of GDP and where a primary component of GDP growth is housing?"

The answer of course, is none. Maybe this time it's different.

How to prepare?

There is a lot of money to be made between now and when it stops working.

Not much us plebs can do. However, if you wish to become one of the self-styled global elite, I believe you just have to have the desire, be great at networking and have a modicum of independent or government derived wealth. Not ironically, I suspect independent wealth goes further for this.

The future (is now)

noreply@blogger.com (Unknown) — Wed, 26 Jan 2022 23:36:00 +0000

Quick post...

In a previous post, I talked about how I thought there would be a greater lock down of society and people would object.

While I'm not sure a greater lock down has occurred, I have noticed that media and self-styled elites are further creating a divide between you-know-who and you-know-who-not. Divide and conquer is a strategy as old as time. Unfortunately, most people are unsophisticated thinkers and fall victim to the game, handing the elite power on a platter. I'm sure I have done the same many times.

In that post I said:

There will be an attempt to wholly lock down society worse than what we've had the past two years. It will fail. It will be messy. It will not work. People will refuse it. People who matter to the smooth running of the economy, which is after all, anything anyone cares about these days.
The cultural elites driving this lock down will be caught off guard as they were caught off guard by he-who-shall-not-be-named. As with anyone losing power, they will try to increase their grip. It will be bad.
But in the end, the people will refuse to participate and will develop the leverage needed to add the right checks and balances to a system that is sorely lacking them. I doubt it will be violent.

We are at that point now where there is a mass trucker protest which they basically can't ignore. They tried, but it is too large now. The truckers matter to the smooth running of the economy. If there are going to be shortages and even worse inflation as a result of this strike, that is the people exercising their power against the government in a nonviolent manner. They can no longer blame a boogieman, even if state run news (lol) refuses to cover it.

The only way governments can respond are as follows:

Accede/respond to demands and begin good faith negotiations
Ignore the demands. Usually leads to government being toppled.
Demand an end to the protest and respond with violence if the protest does not end

Surely there are other possible responses. What does history say governments do when their people protest in a massive organized fashion?

There is a long history of (3) in all professed "developed" countries. One might even say the US government response to Jan 6 falls under (3).

So the Canadian government response will be interesting. Will the enforcers support the leaders if they require violence?

I'm not so sure.

In any case, it will be interesting.

Other countries have already been doing mass protests for a long time. France, in particular. But mass protests in France are like brunch on Sundays, it's not guaranteed, but it'll happen.

Whether you want to believe it or not, the past two years have been basically a gift to the self-congratulating elites of the world. I wish I had the clip handy, but there is a woman at the WEF saying something to the effect of:

The good news is: we, the elite, get along better than ever! The bad news is: no one in our countries trusts us.

She actually did call herself elite. I wish I was kidding.This is how they see themselves. How do they see us?

Joe Rogan covering the protest: https://twitter.com/iwillchaseu/status/1486456133015511047

Update: Justin Trudeau has chosen to leave Ottawa which is a version of (2). Hmm...

The future

noreply@blogger.com (Unknown) — Tue, 26 Oct 2021 23:52:00 +0000

This blog shows that I am often early on trends. It took me a long time to realize this was the case. I'm not necessarily wrong, just early. I also don't really prepare well for trends that aren't potentially disastrous. For example, Bitcoin. Had I known how prices are determined (hint: what someone is willing to pay), I would have made different decisions.

Other trends I saw coming:

Golden handcuffs: The first time I saw someone get fired I said that I will never put myself in a position where I rely on a job. As a result, I have built multiple streams of income which have lasted for decades at this point and every year I try to add one more, usually unsuccessfully.
Remote work: Somewhat tied to the first, I have insisted on remote work (for the most part) for over 10 years. This is mildly tied to the logic here (tl;dr: people hire other people like themselves, I am not like other people so I try to avoid being in that position.) My two favorite positions I left because of lack of remote work instituted remote work within a year after my departure. Only a year early although the two events were nearly a decade apart!
A segregation between the elites and the rest of society. In the 2000s, I noticed that the culture had shifted to propagandizing families against each other. Cultural elites know that at the end, legacy is what matters. I remarked to a friend that marriage will be a consideration only for cultural elites in the near future. A few years later, I came across a really great book which confirmed my suspicions in data.

So what am I seeing today? A societal rip that is being exaggerated by an increasingly irrelevant media desperate to retain its control over the narrative. For a simple example, consider the distribution of feelings of those you know regarding vaccination status. Extreme on both sides, and being promoted by all media. Meanwhile, talk to someone who is off grid, they really don't care. Yes they'll wear a mask when they go into town, and no they won't otherwise.

To maintain control and push forward The True Narrative, the Internet will necessarily need to be locked down. We already saw this with the banning of a US president from social media. In my opinion, this should have shocked everyone, regardless of their political affiliation and should have been vehemently opposed by everyone. However, due to the aforementioned rip, it was quite easy to find out where one stood politically based on how they perceived that event. After all, I don't like the guy so it's better if he doesn't get to speak. This has since spilled over to censoring of all sorts of factual information on platforms like YouTube.

I don't know if I see this getting better without a major loss.

So what is the trend that I am possibly early (or maybe even late) on today?

There will be an attempt to wholly lock down society worse than what we've had the past two years. It will fail. It will be messy. It will not work. People will refuse it. People who matter to the smooth running of the economy, which is after all, anything anyone cares about these days.

The cultural elites driving this lock down will be caught off guard as they were caught off guard by he-who-shall-not-be-named. As with anyone losing power, they will try to increase their grip. It will be bad.

But in the end, the people will refuse to participate and will develop the leverage needed to add the right checks and balances to a system that is sorely lacking them. I doubt it will be violent.

I want to be wrong, but I also don't want to be wrong because I want that new component of checks and balances.

Am I really doing anything to prepare? No, not really. I don't expect it to be disastrous. Plus, I'm probably already late.

If software engineering is in demand, why is it so hard to get a job?

noreply@blogger.com (Unknown) — Mon, 30 Aug 2021 21:27:00 +0000

Title taken from here: https://news.ycombinator.com/item?id=28355658 where there is lots of speculation about why job searching in software is so Kafka-esque.

Without fail, every job I have ever taken is one where I was not super qualified but the other people in the job were like me in some way. Either they were independently minded, immigrants, liked Lisp for whatever stupid reason or wanted to do great things with people who wanted to do great things.

So looking for a job, in software, is about finding people like you. You can be perfectly qualified for the position, but if it's a company full of Chadbros, they want other Chadbros, if it's a company of bronies (yes, I've seen one, it was hilarious, and I loved it), they want people who don't challenge their bronyhood.

Let's take a look at the "About us" screenshots from some recently "Who's hiring" from Hacker News. Note that I'm absolutely not picking on these people, just pointing out some observations.

Commonality here could be: peppy personality

Commonality here could be: fantastic hair

You can keep going and they will all pretty much appear to share some commonality.

For comparison, here is a picnic:

Commonality here could be: people who like to have fun

Notice the picnic have a different "kind of people", even though presumably they all love to see their kids have fun.

So why do tech companies end up looking like the above?

Very simply: they know "their" kind of people and know how to get along with "their" kind of people. Whether this is brony, chad, young, old, culture 1, culture 2, etc, that is what _all_ interviews are about. The actual questions asked in the interview do not matter beyond basic some competence.

This is why interviewing has become a job in itself. Some people think it's perfectly normal to have 5 rounds of interviews but what is really happening here is: "would you like to spend time with this person".

This is also why networking is the best way to get a job if you are looking. You are already "their" people.

If you go for an interview, your job is pretty much to find out if you are compatible. It's a date. You'll know you're in if they help you eagerly with whatever fizzbuzz question they give you.

Yes I know people will say "how dare you, our interview process is supremely objective", but to provide my own anecdata, I've never gotten a job on technical merits, and I've had more than one offer over the years from big tech. Why I didn't take them is another story.

Many years ago, I was interviewing (blind) with one of those "interview with us and you get a job at FAANG" shops. I nailed everything technically, to the point where they said I was the best they had seen (could have been stroking my ego, who knows). I go onsite, and it could have been a bad day, they didn't like my hair, but the chemistry that was there remotely, on the days before zoom, disappeared and even though I nailed their onsite technical interviews as well - implementing Tetris I think - somehow, there was a complete cold distance. Shit, I even did it in Clojure, a language I hadn't learned before that day. So it wasn't technical at all.

It took me a while to understand what actually happened. They were not my people and I was not theirs. In fairness, I am not most people's people. It is what it is.

So look for people who are like you along some axis, or try to find some commonality beyond just answering the questions if you really want a shot at that job.

I realize that adds yet another dimension but in my opinion, it's the most important one.

My honest advice if you are looking for a job is: enjoy the tech interview process. The questions that everyone complains about can be fun and an opportunity to learn, whether you get a job is not even relevant. It's basically luck of the draw in the end. And focus on first impressions, those matter quite a bit.

Y's vs non-Y's (the parable of the software consultant)

noreply@blogger.com (Unknown) — Fri, 30 Jul 2021 22:44:00 +0000

Client: How much do you think it will cost to get the project done?

Consultant: Probably $X in P periods of time

Client: $X is too high, I can get 4 Ys for $X.

Consultant: OK, go for it.

... 2 x P periods of time pass ...

Client: Hey... The Ys didn't work out and the project is almost a writeoff. Can you come onto the project?

Consultant: Since I need to undo the damage first, it will cost $(X+Z)

Client: OK.

(Based on many true stories, names have been changed to protect the innocent.)

In my experience, the reason this happens is because software is eating the world, but deep knowledge of how software is built is still locked up in the old guard, some people coming out of high-tech FAANG-like companies, as well as some independent developers.

The rest of the industry is focused on leftpad-gate, and arguing over Javascript front-end frameworks etc while the art of developing software is honed by very few.

The flip side of the coin is the Y's can actually do a great job when it comes to software that follows a beaten path. For example, a standard web app with a React front-end. This is why everyone wants to know "your stack". Y's beat out non-Y's 99/100 times here in my experience.

Many conflate the proficiency of Y's with their home stack with software development expertise. I have found that this is usually not the case. They are SDK developers (which is perfectly fine, quite lucrative and very useful, please don't get me wrong.) If you take them out of their stack, they are lost.

The proficiency with Y projects (which vastly outnumber non-Y projects) trick you into thinking that you can use a Y for a non-Y project. You cannot.

When you get beyond Y projects, building software to support what is coming down the line is near impossible for Y's since there is no way for them to create something that doesn't exist. Y's can use a stack, but they can't create a stack.

For non-Y's, they are usually not interested in standard CRUD apps with React front-ends, so they are willing to wait for interesting projects to come to them.

I think the Y's and non-Y's are complementary and there is no need to pick a better side.

I know non-Y's who wish they could be Y's and I know Y's who yearn to be non-Y but do not get the opportunity. Maybe their paths are chosen years in advance by some fluke of life and the results compounded without their active consent.

Achieving goals using TeamCity

noreply@blogger.com (Unknown) — Wed, 03 Aug 2016 15:10:00 +0000

As a small company of 1 + sub contractors, I have very little room or patience for doing things I don't need to do. The concept of being an architecture astronaut is not new to me, as I have both designed and coded myself into a corner in the past so I am acutely aware of the YAGNI philosophy.

A very important class of tasks fall into the bucket of "things I need to do, but manually." This might include:

Updating a sales database
Generating development metrics to guage project health
Monitoring license count/usage, bumping the count if needed or "upselling" the end user
Announcing releases

These are all real tasks that I need to do every day/week/month. All of these are manual. Slowly, but surely, I am replacing them with automated scripts. That's not really too interesting.

The interesting part is that I'm using TeamCity to create the workflows to support all of these. At a quick glance:

TeamCity: not just for building software

Some projects/configurations are hidden, but this gives you the general idea. I not only use TeamCity for building and testing the software I write, but I use it to export sales, update mailing lists, generating development metrics and even automatically creating blog posts/emails announcing new releases.

Why would I do this?

Basically, I am buying myself time. By putting in a little bit of work ahead of time, I save myself man-months of work in the future.

What this really allows me to do, and is the ultimate goal, is focus on talking with customers. To create conversations with customers, you have to give them something they can talk about in the first place.

So every thought process is geared towards getting the customer communicating their pleasure, or displeasure with software they use.

Why is TeamCity the right tool to do this?

Well, for me it works because:

I already use it and know it
TeamCity has a very good concept of inputs and outputs: build artifacts. This is primarily what makes my non-build workflows possible
My design process is agnostic of the tools/techniques I use, and so I can fit in whatever tool works best.

But before I choose the tool, I have a process for choosing an implementation. I've outlined the process below. I cannot take credit for this process as it was taught to me and I've honed it in the last little while.

The process

1. Choose a goal

Before I choose a tool to do the job, I look at the goal. While the high-level goal is obviously customer satisfaction (80% of people choose the "It's just perfect - thanks mom" option in recent surveys so I'm hitting that target pretty well), there are sub-goals that will help me get there. For an example, let's pick the "Notify customers of an update" goal.

2. Create a design

Next, I create a design to implement the goal. For example, here is the design I used to determine what happens when I commit a change. It's pretty standard though this evolved over the period of a few months. The purpose of creating this design is to let me go back to it and modify it when things change. Nothing is in my head, it's all here. This is a huge difference from only a couple of years ago where I would keep everything in my head.

3. Mark up the design where tools implement the required functionality

The next step is usually to print it out and circle places where I think tools will do the job I need. I simulated this with SnagIt as I only JUST recycled my actual notes for this particular diagram. Murphy's Law strikes again.

Why do this? Very simple: who wants to write a ton of code that isn't necessary? Outsource as much as possible to free (as in beer) software, commercial, whatever is needed to get you to your goal.

By doing things in this way, and keeping an eye on choosing things that let me do as little work as possible, I end up with a very lean design and most importantly, a lean implementation.

You can see the big arrow is the key piece here allowing me to outsource nearly 100% of the "notify users of an update" functionality. By linking in certain libraries on certain platforms and generating a very specific format of an update manifest, I can support updates on Windows, OSX and Linux.

In particular, Linux was super simple. Can you match the code below to the design above? It should be pretty straightforward.

cd $WLA_ROOT/build

export GNUPGHOME=$WLA_ROOT/dev/ci/keys/gpg

$WLA_ROOT/dev/scripts/run_gpg_command dpkg-sig -g " --yes" \

--sign builder *.deb && \

rm -rf repo && \

mkdir repo && \

cp *.deb repo && \

cd repo && \

(dpkg-scanpackages . /dev/null > Packages) && \

(bzip2 -kf Packages) && \

(apt-ftparchive release . > Release) && \

($WLA_ROOT/dev/scripts/run_gpg_command gpg --yes -abs -o Release.gpg Release) && \

(gpg --export --armour > archive.key)

So... Why did you choose TeamCity when an actual workflow tool would do just fine?

Here is a version of the markup that makes it obvious where TeamCity can help: the package and manifest are treated as artifacts. The screenshot below, directly from TeamCity shows how treating the inputs and outputs as build artifacts allows the use of TeamCity as a tool for the rest of the process (after building and testing is complete):

Inputs for the "notify users of an update" box matching nearly 1:1 from design above. Linux has "15" because the "manifest" is a directory with a bunch of files in it so apt/yum can do their job. Technically, I could zip that directory up and make it a single artifact.

What else do I get for free?

This is my favourite part of doing things like above: you get a ton for free. By integrating the everything into TeamCity, I get:

Build history
Artifact history
Configuration management
Project metrics (I specifically track LOC to make sure I'm not going too crazy):

Conclusion

I just wanted to record my thought process for posterity. Enjoy!

There is a very simple reason why the DAO was easily hacked

noreply@blogger.com (Unknown) — Thu, 02 Jun 2016 03:35:00 +0000

Background here. TL;DR: a smart contract "worth" about $150 million USD was "hacked" and had $45 million USD moved to accounts controlled by the hacker.

The "DAO" is an instance of "code as legal contract" run using a Bitcoin-like technology called Ethereum. The programming language for Ethereum is imperative for reasons that escape me, but are probably legit - likely simplicity and user friendliness.

There is a very simple reason why the DAO was easily hacked: the code is shit.

The contract (it doesn't matter if this is the deployed version or not) is about 300 lines long. It has the equivalent of 15 constants, 15 public fields, 2 nested classes and 25 functions.

25 functions all jumbled into one contract.

Would you let this pass code review? Most people would not. The organization of this contract was such that the quality of implementation was obvious from a first glance. The fact that this "hack" exists is not surprising. 25 operations on a type indicate that there is too much flexibility, and likely very little thought went into creating the correct abstractions. I say this from humbled experience.

As long as the Ethereum miners don't bail out the DAO, the concept of the Ethereum blockchain is fine. The DAO should fail to teach them a lesson. Bitcoin went through its own growing pains with all the exchange hacks forcing beefing up security.

There is an ongoing discussion on Hacker News about the code behind the contract.

All that being said, this incident should not turn people off Ethereum so long as the miners don't bail out the DAO. The technology is interesting, and this is the equivalent of the Araine 5 explosion for Ethereum. A learning experience.

Why I moved to Git from Mercurial

noreply@blogger.com (Unknown) — Sat, 06 Dec 2014 15:03:00 +0000

There are stories everywhere about how Git is eating everyone's lunch. For a long time, I happily used Mercurial primarily because I needed a cross-platform DVCS that had a sane command-line interface. I don't think there is much disagreement that the first few iterations of git were not very portable nor was the command-line very friendly. Mercurial has been in daily use by me very nearly since it came out and I don't have any complaints. It's that good. So why move?

One word: Magit.

The only Emacs packages for Mercurial I tried (vc.el and Monky) were very basic. Monky, an imitation of Magit, was a very superficial approach and vc.el still hasn't moved very far out of the days of centralized version control, though it has somewhat. Additionally, Magit has a killer feature that rightfully matches Git's killer feature: editing the index.

ADHD Coding and the Index

Sometimes, due to what I assume is late-blooming ADHD, I go on development tangents where I fix bugs and/or add little features here and there. When it comes time to commit, I have many changes intermixed with one another and committing them all at the same time is a terrible idea for a clean, readable history.

Git's source editing process works like this: edit -> stage -> commit. Until you stage something, it cannot not be committed. Take a look at the Git book for more information.

What Magit allows you to do superbly (obviously through Git), is within each file, "stage" the only the changes you want. So if you have 3 blocks of changes within a file, you can choose to only stage the one change without reverting the other 2. Now you can commit related changes together even if you worked on multiple things at the same time.

So when using the ADHD development methodology described above, staging diff hunks is ridiculously helpful and Magit makes it easy to do the right thing even for simpletons: s for stage, u for unstage. I never did try very hard to figure out how to do it with Mercurial but I think I remember hearing the word "plugin" or "queues" before I zoned out.

Projects

I've moved most of my private repositories, including my JIRA time tracker over to Git as well as my dependency injection library for C++. Switching to Git for continuous builds was easy as pie. The only real change I had to make was the bit of the build that grabbed the HEAD revision:

diff --git a/ConfigureWorklogAssistant.cmake b/ConfigureWorklogAssistant.cmakeindex 988f6c4..1fb5d36 100644
--- a/ConfigureWorklogAssistant.cmake
+++ b/ConfigureWorklogAssistant.cmake
@@ -32,8 +32,9 @@ macro(define_kimi_product OutputFileVar ProductGUID CompanyName

   set(KIMI_PRODUCT_SOURCE_REVISION)
   execute_process(
-    COMMAND hg head tip --template "{rev}"
+    COMMAND git log -n 1 --format=%h
     OUTPUT_VARIABLE KIMI_PRODUCT_SOURCE_REVISION
+    OUTPUT_STRIP_TRAILING_WHITESPACE
     )

   configure_file(

The future

I am pretty much set with Git for now. The fact that it only took a few hours is probably a testament to how similar the two are. However, if Mercurial was to develop an interface as good as Magit, including supporting some form of staging in a big way, I think I would consider switching back. A DVCS written in Python is too delicious to ignore.

A walk through a cool code generation trick from Clang

noreply@blogger.com (Unknown) — Thu, 30 Oct 2014 13:25:00 +0000

[edit: fixed css]

If you don't know, Clang is an open source C, C++, Objective-C and Objective-C++ front-end for the LLVM compiler. Clang/LLVM contributors are probably some of the brightest software engineers you'll come across so there is always something to learn. Take a look at LLVM weekly to see the kinds of things people are working on. Just in the last week:

Improved MSVC/Golang/GCC support/compatibility
New intrinsics for the LLVM IR
A disassembler for the Hexagon backend

If you want to dig into the architecture of Clang/LLVM, you should read the LLVM chapter from "Architecture of Open Source Applications". In fact, both volumes of the book should be mandatory reading for anyone interested in software design and architecture.

The Clang Philosophy

Figure 1: The Clang Philosophy, summed up by Xzibit

When building Clang itself, you are actually using 3 code generators:

The C++ compiler you are using to compile Clang
The C++ preprocessor
A DSL-to-C++ code generator called tblgen - yes, there is
literally a custom compiler used to build clang!

tblgen is run during the build process to generate (usually) C++ code. Although I'm not aware of it generating anything else, it could conceivably be used to do so. The purpose of the program is to help the developers maintain lists of domain-specific information. For example: allowable attributes on a function or types of nodes in the AST.

Here is the example we're going to look at: Attr.td. In particular, we'll follow the lines below into the final C++:

class MSInheritanceAttr : InheritableAttr;

def SingleInheritance : MSInheritanceAttr {
  let Spellings = [Keyword<"__single_inheritance">];
}

During the build, tblgen is given Attr.td which it parses into a AST and processes:

OS << "#ifndef LAST_MS_INHERITABLE_ATTR\n";
OS << "#define LAST_MS_INHERITABLE_ATTR(NAME)"
" MS_INHERITABLE_ATTR(NAME)\n";
OS << "#endif\n\n";

Record *InhClass = Records.getClass("InheritableAttr");
Record *InhParamClass = Records.getClass("InheritableParamAttr");
Record *MSInheritanceClass = Records.getClass("MSInheritanceAttr");
std::vector<Record*> Attrs = Records.getAllDerivedDefinitions("Attr"),
      NonInhAttrs, InhAttrs, InhParamAttrs, MSInhAttrs;
for (std::vector<Record*>::iterator i = Attrs.begin(), e = Attrs.end();
     i != e; ++i) {
  if (!(*i)->getValueAsBit("ASTNode"))
    continue;

  if ((*i)->isSubClassOf(InhParamClass))
    InhParamAttrs.push_back(*i);
  else if ((*i)->isSubClassOf(MSInheritanceClass))
    MSInhAttrs.push_back(*i);
  else if ((*i)->isSubClassOf(InhClass))
    InhAttrs.push_back(*i);
  else
    NonInhAttrs.push_back(*i);
}

EmitAttrList(OS, "INHERITABLE_PARAM_ATTR", InhParamAttrs);
EmitAttrList(OS, "MS_INHERITABLE_ATTR", MSInhAttrs);
EmitAttrList(OS, "INHERITABLE_ATTR", InhAttrs);
EmitAttrList(OS, "ATTR", NonInhAttrs);

Something you should probably take note of is how easy the code is to read and understand. This is the rule rather than the exception. In any case, the final result of tblgen (in this case) is a header file, AttrList.inc, part of which is reproduced here:

MS_INHERITABLE_ATTR(MultipleInheritance)
MS_INHERITABLE_ATTR(SingleInheritance)
MS_INHERITABLE_ATTR(UnspecifiedInheritance)
LAST_MS_INHERITABLE_ATTR(VirtualInheritance)

I know, it's not very impressive. But check out what I can do now (this probably doesn't actually work):

static const char * MsAttrs[] = {
#  define MS_INHERITABLE_ATTR(Name) #Name,
#  define LAST_MS_INHERITABLE_ATTR(Name) #Name
#    include "clang/Basic/AttrList.inc"
#  undef MS_INHERITABLE_ATTR
#  undef LAST_MS_INHERITABLE_ATTR
};

int main() {
  std::cout << "All MS attrs" << std::endl;
  for( auto attr : MsAttrs)
    std::cout << attr << std::endl;
}

By listing a bunch of domain-specific "records" in a manner that can be used by the preprocessor, I can now do whatever I like with those records! I've used this to great effect in my own code (from my JIRA time tracker). Here is a snippet of JiraTaskAttrs.inc which contains a list of attributes for a task:

JIRA_TASK_ATTR(Key)
JIRA_TASK_ATTR(Summary)
JIRA_TASK_ATTR(Description)
JIRA_TASK_ATTR(Type)
JIRA_TASK_ATTR(TypeIconUrl)
JIRA_TASK_ATTR(ProjectKey)
JIRA_TASK_ATTR(ProjectName)
JIRA_TASK_ATTR(ProjectImageUrl)
JIRA_TASK_ATTR(Priority)
JIRA_TASK_ATTR(PriorityIconUrl)
JIRA_TASK_ATTR(Status)
JIRA_TASK_ATTR(StatusIconUrl)
JIRA_TASK_ATTR(Resolution)
JIRA_TASK_ATTR(Security)
JIRA_TASK_ATTR(Assignee)
JIRA_TASK_ATTR(Reporter)
JIRA_TASK_ATTR(Labels)
JIRA_TASK_ATTR(AffectsVersions)
JIRA_TASK_ATTR(FixVersions)
JIRA_TASK_ATTR(Components)
JIRA_TASK_ATTR(TimeEstimated)
JIRA_TASK_ATTR(TimeSpent)
JIRA_TASK_ATTR(TimeRemaining)

Using this header file, I can generate enumerations:

enum TaskAttr{
# define JIRA_TASK_ATTR(Name,...) TaskAttr_##Name,
#   include "JiraTaskAttrs.inc"
# undef JIRA_TASK_ATTR
  NumTaskAttrs
};

Or function definitions:

#define IMPL(Enum)                                                      \
  QString                                                               \
  KJiraRepositoryType::TaskAttr_ ## Enum() const {                      \
    return toQString(model::Task::getAttrColumnName(JiraRepositoryType::TaskAttr_ ## Enum)); \
  }

#define JIRA_TASK_ATTR(Name,...) IMPL(Name)
#include "common/connections/jira/JiraTaskAttrs.inc"

Here is another example from the same project of how I use this trick to enumerate configuration values: Source, C++. I've used this in numerous other places, but this should give you an idea of the types of things that are possible using just the preprocessor and a little forethought.

Conclusion

A good way to become a better craftsman is to learn from others. Software developers are kind of lucky because we have come up sharing the tools of the trade. The open source Clang compiler offers the combined experience of many intelligent software engineers and as a result, there are many tips to be learned that can make you better at your own job. So start reading today!

Moving from SCons to CMake

noreply@blogger.com (Unknown) — Sat, 24 May 2014 14:33:00 +0000

TL;DR: I'm happy with CMake + Ninja, even though the language is ugly and the speedup is not that impressive.

I'm not ashamed to admit it: I stayed away from CMake because the language seemed inelegant.

Elegance and beauty can be defined in many ways but context is apparently important. Maybe this is why the most beautiful language in the world is relegated to being used as an extension language for my editor rather than to run the world.

I am currently in the middle of a project moving from SCons to CMake and I am pleasantly surprised at the quick progress. The SCons project has about 3KLOC of SCons build scripts that do everything from generating code for language bindings to building 20-something external C and C++ libraries. My experience with this larger project has also convinced me to move over my JIRA time tracker, because of all the other things I should be doing, the most important thing is moving over the build system for no particular reason at all.

SCons served the larger project well when it started. Python was an easy language to learn, if not master and so most people could read the code and make little modifications when they needed to. As the project grew and things got more complicated to manage, we started mimicking other build systems to add features that SCons did not have. The most important feature we cribbed was the "use requirement" feature from Boost Build. In a nutshell, it allows you to attach "arbitrary" requirements to a target that you are consuming. So if you use SomeFunkyDll.dll in your project, you may want to require that the library clients define SOME_FUNKY_DLL when they consume it. Automatically doing this in SCons was a big pain in the rear. I don't need to tell you how we did it because it is not relevant but I wanted to give you an idea of the types of things we found important.

Another problem that the project started having is once we passed some critical mass of source code, the build seemed to slow down significantly. In the old days, SCons could be slow as molasses because it wanted to be correct over everything else. We tried everything in the "go fast" recommendation list but at best, a no-op build took a long time and this was resulting in too many sword fights.

Eventually, we got to the point where we thought that working on this project was becoming inefficient so we looked for alternatives. I had always had CMake in the back of my mind as I had actually written my own makefile generator for another project. The architectural separation of specification and the actual build actions allowed optimizations at different levels not unlike a compiler which allowed me to add many more features than I would have been able to had I had to also develop the build action logic.

I won't be talking about the larger project yet (maybe ever) but I will talk about my experience moving over Worklog Assistant's build system. Just so that there is a frame of reference:

Number of targets in build (including third-party files): ~1K
Lines of app code (excluding third-party files): ~20K

That is, it's not a huge project.

A post on build systems can go on forever, but the performance of the build for each of these activities is what actually matters to me when I'm doing my daily work:

Clean build
Modifying a core header file (aka a file that nearly everything depends on)
Modifying any cpp file in the build
Modifying an important, but not core header file
For some reason this seems to be important when comparing build systems: building when nothing changed. I don't personally care about this metric.

Each of these will have some sort of relative importance and for me, the activities where build performance matters most are modifying non-core source and header files. The rest have minimal importance.

The CMake language, other weirdness and leaky abstractions

My initial aversion to CMake was likely due to the fact that it was clear to me there would be weird conventions and things that worked kind of differently depending on the backend chosen. I was not wrong in this assumption, but I was wrong in how much they would bother me: not much. Don't get me wrong, it's frustrating not completely understanding why changing an add_custom_target to add_custom_command makes things work "better" with generated files, but by and large, there are few such design bugs.

The biggest reaction any decent developer probably has when being introduced to CMake is the language. It just looks bad. However, while the language is not efficient by any means, nor is it beautiful, it is predictable and regular which makes it easy to learn. After the initial shock of the aesthetics of the language, you settle into it pretty easily. Thought: perhaps the language being intellectually unappealing encourages the developer to spend as little time in it as possible making him/her quite efficient. Did they learn this from Java? Hmm.

Different build systems

I have not launched Visual Studio to do a build since perhaps 2008. There are many reasons to do so however. Comfort and familiarity being one. Incredibuild is another. I think this is the main reason why CMake will eclipse all other C++ build systems: it is a 1-to-N solution. That is, one team's preference to fulfill their requirements can support the particular preference of N other teams to fulfill theirs. This is not possible with other build systems.

Third-party library support

What surprised me the most was how often there were CMake modules available to use for $MY_FAVOURITE_LIBRARY. This allowed me to treat the building of third-party code as a black box by simply adding a call to add_subdirectory or adding the appropriate path to CMAKE_MODULE_PATH and adding a call to find_package. CMake would just use the right compiler and the right flags to avoid build incompatibilities. Previously, I'd just write build scripts for the third-party code myself. Win.

A highly unscientific test with lots of numbers to look official

Here is a nice chart:

All tests are run with the C++ compiler that comes with Visual Studio 2013 SP1.

scons -j8: A fairly well-optimized SCons build using many of the tips from the SCons wiki, run with 8 parallel jobs. Source lists are built dynamically, using a recursive glob + wildcard filter.
cmake + ninja 1: An unoptimized CMake (2.8.12.2) build using the Ninja stable release from September 2013. Source lists are built with a preprocessing step and some elisp to make maintenance of the preprocessed file easier. See gist.
cmake + ninja 2: Same as cmake + ninja 1, but configured with CMAKE_LINK_DEPENDS_NO_SHARED=ON
cmake 3.0 + ninja: Same as cmake + ninja 1, but using cmake 3.0
cmake + ninja latest: Same as cmake + ninja 1, but using Ninja from git

This looks pretty OK! CMake and Ninja beat SCons. But this is only part of the story. Here is the actual data:

	Importance	scons -j8	cmake + ninja 1	cmake + ninja 2	cmake 3.0 + ninja	cmake + ninja latest	cmake 1 % speedup	cmake 2 % speedup	cmake 3.0 % speedup	cmake + ninja latest % speedup over scons
Clean build	5%	224	279	264	266	261	-24.55%	-17.86%	-18.75%	-16.52%
Touch core header file and rebuild	5%	165	178	174	180	175	-7.88%	-5.45%	-9.09%	-6.06%
Touch a source file and rebuild	50%	46	35	35	35	35	23.91%	23.91%	23.91%	23.91%
Touch an arbitrary non-core header file and rebuild	40%	60	68	65.5	66	65	-13.33%	-9.17%	-10.00%	-8.33%
Do-nothing and build	0%	10	0.5	0.5	0.2	0.44	95.00%	95.00%	98.00%	95.60%

Weighted average	100%						5.00%	7.12%	6.56%	7.49%

The Ninja build sees only a significant improvement over SCons when modifying source files but it has a terrible result when it comes to touching header files. I have my own theories as to why, but running ninja -d stats showed that loading the dependency file was the biggest slowdown.

The weighted average is computed using the "importance" column. I think touching source files should perhaps have a higher importance than I've given it above. Do I really edit header files as often as source files? I don't have the answer to that so as a proxy, I just ran a simple script counting how many header files vs source files were touched in a 6 month period and applied the ratio as a weight. My gut feeling is that I probably spend more time editing source files than header files.

Conclusions

Not as clear cut a win as I had hoped: a well-optimized SCons build can still be faster for some sizes of projects and it is possibly more correct. However, the equivalent SCons build does require more maintenance to provide the same features as one in CMake. I found that compiler/toolchain support is much better with CMake than with SCons and I write less code to do the same (complex) thing. Occasionally, CMake's abstractions leak making it awkward to do simple things like generating files, which are easy with SCons. On the other hand, CMake makes it easy to add per-file compile options which are difficult with SCons.

Since the performance for this particular example is roughly equal, I have to choose the system that makes me feel more productive. And by that metric, CMake + Ninja make me "feel" more productive only because Ninja starts building immediately.

What matters even more: the SCons community has always been small. The CMake community on the other hand is huge in comparison and is only growing. I expect performance to improve and more backend options to become available that improve performance.

I had about 4 or 5 years of SCons experience that went into the build for this project. This means there are a lot of little performance tricks I applied and as my experience with CMake is not nearly as long, it isn't a fair comparison. I should be ashamed of expecting a free speedup, but the speedup I did see for an important use case makes me feel as if it was worth it.

On the upside, I no longer have to wait for SCons to start building something after hitting compile.

Have you transitioned to/from CMake? I'd be curious to hear about your experiences.

Interesting links

SCons
Parts - A promising extension to SCons
Ninja
Ninja, a new build system - Blog post about the birth of Ninja
GYP: Generate Your Projects - Yet another makefile generator

So I was right about the vector, wrong about the players

noreply@blogger.com (Unknown) — Mon, 12 May 2014 23:52:00 +0000

You will cringe hard when you read how I wrote about C# many years ago but I had honestly expected this to happen to C#, not Java. Maybe having C# as a ISO standard actually had some benefits.

Will there be a Heartbleed-like crisis where these ideas will cause a reckoning for the industry? As I understand it, the licensing for implementing the x86/x86_64 ISAs reached monopoly level years ago, actively shutting out competition. The main hardware innovation is now coming from mobile where x86 can't yet compete. PC sales have been leveling out ever since the introduction of iStuff. I don't think the three are correlated, but it is interesting.

PS: If you still want to be friends, do not read the rest of the content on that first link. Oh man.

Design by committee works slowly

noreply@blogger.com (Unknown) — Thu, 21 Mar 2013 15:12:00 +0000

The latest draft for polymorphic lambda expressions, which I advocated for in a post about 3 thousand years ago, is a step in the right direction. I greatly appreciate the time that the authors are taking to push C++ forward. I know they do it on a volunteer basis and I believe their passion for it makes C++ one of the best languages to use for a variety of projects. On reading the draft though, I'm still a little underwhelmed.

Lambda expressions are anonymous functions that are common in languages with first-class functions like Lisp. Roughly, the language gives you the ability to create functions "at runtime" which allows you to store data and other state. Once this is possible, anything is possible. You can read more about anonymous functions at Wikipedia.

When a programmer uses anonymous functions, he or she is not doing it for a technical reason (i.e., performance) They are doing it for one or all of the following reasons:

Lexical locality: The data that the anonymous function will be operating on is somewhere nearby and we just need to do a little transform on it to make it useful to something else which is also nearby.
Readability: x => 2*x+y is much easier to read and understand than MyFunctor f(y) because you need to go look up the definition of MyFunctor.

In x => 2*x+y, you can see that the 'y' value must come from somewhere else in the function: capturing data in lexical scope is an important part of anonymous functions. This is the reason why MyFunctor takes in 'y' as a parameter.

Anyway, as my post tried to explain, one of the main problems is the ridiculous verbosity implicit in monomorphic lambda expressions. By allowing polymorphic lambdas, the verbosity has a chance to be reduced or even eliminated to the simplest possible thing. The latest draft makes an "auto" necessary on lambda expression parameters.

To recap, C++11 lambda expressions transform a statement like:

[](double slope, double intercept, double x){ return slope * x + intercept; }

into a function object not completely unlike:

struct LOL
{
double operator()(double slope, double intercept, double x){ return ... ;}
};

Most lambda expressions will only ever be used with one set of parameter types and in one situation so it is not hard to understand why this is one acceptable syntax. However, languages like C# have much more concise syntax for the above case:

slope,intercept,x => slope * x + intercept

The compiler figures out the types since it is a statically typed language and everyone is happy.

Before lambda expressions, in C++, we might have written:

namespace bl = boost::lambda;
... bl::_1*bl::_2 + bl::_3 ...

My goal for C++ lambda expressions would be to never use any of the Boost lambda libraries again, as useful and awesome as they are. With the new draft, the C++11 version becomes:

[](auto slope, auto intercept, auto x){ return slope*x + intercept; }

As you can see, the above Boost Lambda form is arguably still preferable to the draft version of polymorphic functions just on length alone. And although it is longer, it is slightly easier to read and understand because of the named parameters. But why can't we spoil ourselves? There aren't too many technical tricks required to automatically turn:

[](slope,intercept,x){ return slope*x + intercept; }

into the same form behind the scenes.

In my humble opinion, the auto actually adds nothing to readability and takes it away because I am required to read more to understand what is going on. Multiply this by thousands of expressions and multiple projects and it is just another thing I have to skip over. There is actually very little reason to require auto. With this extension, it is still easier to use Boost Lambda

The 5 people who voted "strongly against" making auto optional should rethink their votes. This is the best chance we have of getting it right the ~~first~~second time.

Learning about Bitcoin or why I'll never use Bitcoin

noreply@blogger.com (Unknown) — Sun, 29 May 2011 21:13:00 +0000

Bitcoin is quite a promising e-currency. Created by some-guy-we-don't-really-know-or-a-double-agent-of-some-kind-who-is-probably-quite-Bitcoin-rich-now, it has some very useful properties:

Creation of the money is an implicit and transparent agreement between users. That is, there is no centralized issuing authority and there is a finite quantity. Almost like gold.
It is completely electronic and therefore very cheap to transfer. As a result, transaction fees are "low".
Transactions are anonymized, yet completely public to avoid against double-spending.
Some crypto stuff to make sure it is as secure as it can be today

The main desired outcome of a currency with these rules is autonomy of the currency from the somewhat arbitrary influence of centralized planners.

How you are supposed to use Bitcoin

So how do you use Bitcoin (BTC) as a consumer or vendor? Let us assume that you already have some BTC in your account.

Visit place of business
Locate item of interest which costs 0.02 BTC
Go to cashier
Pull out smart phone with your Bitcoin wallet or some kind of link to your Bitcoin wallet
Use QR-code at register to find vendor's payment address. This address will likely be generated at the point of purchase
Send Bitcoin to that address from your Bitcoin wallet
The cashier and network verifies your payment (speed depends on transaction fee) and you go on your way

This is how it would work today if a business accepted BTC. I expect that if I am wrong and if Bitcoin does indeed take off, there will be clearing houses to speed up transactions like these. I think that these confirmations will necessarily be done outside the network but eventually, the network will also validate these which will be the final settlement step.

This exchange is appealing for various reasons. My favourite one is that the users of the system itself benefit by confirming transactions. That is, you can make Bitcoin just by verifying transactions.

Bitcoin Wallet

It is probably useful to discuss where Bitcoins are stored. This location, a file on your hard disk, is called a wallet. It consists of a set of private keys that correspond to each address generated as in the above scenario. This is your vault. If it is stolen in unencrypted form, your money is probably as as good as gone. But the coolest part is that if you have a backup and it was encrypted, you simply transfer the money to an account in a new wallet before the thieves are able to crack the encryption and almost by magic, your money is back again.

Anonymous vs Anonymized

Earlier, I said that transactions are anonymized. This is different from them being anonymous because an anonymizing technology does not imply anonymity. A transaction being anonymous means untraceable which is something that is quite easy to disprove in the BTC world.

Let's start at the beginning. How do you get BTC? There are a couple of ways. One way involves a lot of geekery and stuff that very few people have time for. This is called Bitcoin mining. For most people, just outright buying BTC like they buy USD is the most convenient. Currency is a proxy for labour so it is fine to buy BTC. As the market will continue to be volatile due to the simultaneous debasing of the USD, demand-side pressure as well as the continuous creation of BTC, I would spread out bigger purchases over a few months.

A convenient way to buy BTC is through an exchange. So let us walk through that process:

Create an account with a BTC exchange. I used Bitcoin Market. This requires you to give them two things: an email address and a Bitcoin payment address. Notice how your email address is tied to your BTC address.
Figure out the trade you want to make. I used BMBTC for PPUSD where BM = Bitcoin Market and PP = PayPal.
Execute the trade by making a payment to some email address on PayPal.

When I executed this process, it took a total of 15 minutes for the trade to complete but it was a full hour before the money was in my actual wallet and verified by the network. You must note that this is the equivalent of someone on the other side of the world paying me $10 and someone delivering that $10 to me personally. Not to a bank account, not a promise for $10, but cold hard cash to me personally.

Notice that the process of conveniently buying BTC itself has multiple weak links:

Your email address is tied to a Bitcoin address by Bitcoin Market
Paypal knows who you are definitively through the use of your credit card
Some random dude knows you bought some BTC

To avoid leaking too much information, you can create a new receiving address for every trade and update it on the Bitcoin Market. Note that Bitcoin Market has full trade information and PayPal has amount information. To reduce the risk there, you can use anonymizing email services or a special email just for Bitcoin purchases.

The main point is that once you use a credit card or a personal email address, your anonymity is compromised.

That's not such a big deal, to be honest. After all, you already trust a lot of people with your information online.

De-anonymizing the transactions

If the seller of the BTC was interested in which address bought the BTC through the exchange, s/he would just track the blocks for the specific amount.

When I purchased my BTC, I chose 2 BTC to see how difficult it would be to find in the block explorer. It was pretty easy! Why? Because I knew there would be three related transactions: one for 2, one for 1.99 and one for 0.01 (transaction fee by exchange.) The seller would know this as well.

So all I did was wait for a few blocks to come through the explorer and opened them all up in a browser tab and searched for 1.99. It took less than a minute.

So now, the seller of the BTC has tied my name (through Paypal) to an address.

You may be interested in the actual transaction as currently being confirmed by computers worldwide. Because of this decentralized confirmation, it is now impossible for the seller to re-sell the same BTC to someone else.

Using my Bitcoin or why I'll never use it

Can you figure out what I did with my BTC? Actually, you have all the information you need in this blog post. Once you figure it out, you'll understand why I'll never use it. The first person to add a comment with the right answer and their Bitcoin receiving address will get the remainder of my balance transferred to their Bitcoin address. It's not much, but I probably won't use it...

How to stay anonymous

There are ways to stay anonymous by obfuscating the block chain. However, this is not right. For a currency to be useful, its primitive form must be practically anonymous and not just anonymizing.

How I'd change Bitcoin

My main issues with Bitcoin:

Not anonymous: Identity "anchors" are very easy to establish by transacting with people as described above. This leads to a situation where an attacker can find out what you spend your BTC on for their own nefarious purposes.
The currency has no decay value. That is, it can be hoarded without consequence. I would like BTC to expire so that the currency can keep circulating. This maintains the value of the currency but prevents hoarding. The block chain has enough information to do this. Miners should be interested in this because it means they can continue to mine forever and keep a healthy Bitcoin economy.

I think the anonymity problem is the most hard to solve. I am only concerned with the ability to transfer coin between my own accounts easily without notifying anyone else. If some way could be devised to solve these problems, goodbye centralized currencies.

Deconstructing a dependency injection-driven application

noreply@blogger.com (Unknown) — Wed, 27 Apr 2011 00:13:00 +0000

I've been using my C++ dependency injection library for a project in the last year and it's gone pretty well. There are a lot of rough edges but I thought it could be interesting to the 3 of you still subscribed to this blog to de-construct the stock quote application.

About the application

The example itself is pretty straight forward. You have a choice of 3 stock quote providers: Yahoo!, static and phone. You choose one and ask for a stock quote. Magic happens and your stock quote arrives.

Example session (with some debug output)

Welcome to the DI Stock Quote App. Simplifying and complicating software development since 2010.
Which stock quote service would you like to use?
1: static
2: phone
3: yahoo
Enter your choice (1-3) and press enter: 3
You chose: yahoo
[DICPP]: No scope constructing: di::type_key<YahooStockQuoteService, void>
[DICPP]: Constructing: di::type_key<di::typed_provider<HttpDownloadService>, void>
[DICPP]: Completed constructing: di::type_key<di::typed_provider<HttpDownloadService>, void> with address: 0x100750
Stock symbol (type quit to quit): goog
[DICPP]: No scope constructing: di::type_key<HttpDownloadService, void>
[DICPP]: Constructing: di::type_key<boost::asio::io_service, void>
[DICPP]: Singleton: constructing: di::type_key<boost::asio::io_service, void>
[DICPP]: Completed constructing: di::type_key<boost::asio::io_service, void> with address: 0x1008a0
Current price for goog: 532.82
Stock symbol (type quit to quit): quit

See how the construction of the HTTP service is automatically delayed until actually needed. This is done through a concept called a "provider" which is basically an automatically generated factory.

About Dependency Injection

A really good introduction to the dependency injection technique as implemented by Guice can be found here. It's probably one of my favourite tech talks of all time.

Anyway, to refresh your memory, here are some of the main benefits of the technique used in Guice:

Object construction and lifecycle management is mostly handled for you.
Less boilerplate.
Makes code more testable.
Scopes (~object creation/lifecycle) can be customized by the user.

In short: a lot of the time, you no longer need to allocate objects or pass some object unused down multiple layers of functions or object constructors just to use them once way deep down in some code.

Magic!

I don't really recall how it is done in Guice but in the C++ library linked above, this magic is driven by a type registry which recursively registers constructor arguments as well as user customizations.

In extreme cases, you can initialize an entire application with a few lines of code:

  di::registry r;
  r.add( r.type<MyApplication>() );
  r.construct<shared_ptr<MyApplication>>()->execute();

This constructs the type registry which is a kind of factory. There is a mini-DSL for describing how you want the registry to handle the type. More on this later. In this case, we are asking the registry to "learn" about the MyApplication type as well as all objects that are required for constructing MyApplication.

"Pish-posh", you say. "MyApplication has a 0-arg constructor. I could do that in my sleep."

Would you be surprised if I said that the MyApplication type actually has 3 arguments?

Well, the above is almost what the StockQuote application looks like. Here is the main function for the stock quote example:

di::injector inj;
inj.install( StockQuoteAppModule() );

StockQuoteApp & app = inj.construct<StockQutoeApp&>(); // lifetime
app.execute();

And here is the constructor for the StockQuoteApp type:

DI_CONSTRUCTOR ( StockQuoteApp ,
                ( boost :: shared_ptr < UserInterface >  ui , 
                 boost :: shared_ptr < StockQuoteServiceFactory >  factory ));

When we ask the "injector" to construct the StockQuoteApp instance, it automatically creates the UserInterface as well as the StockQuoteServiceFactory instance.

The di::injector type is just a thin wrapper around the registry so you can treat it as such. The only thing it really provides is a little bit of syntax to allow you to create modules in a similar manner as Guice. The guts of StockQuoteAppModule accept a registry as a parameter and register the various types. You can see the mini-DSL referred to earlier:

void
StockQuoteAppModule::operator()( di::registry & r ) const
{
  // In each module we define the module's root objects, in this case,
  // StockQuoteApp as well as implementations/specializations of any
  // abstract classes. For example, UserInterface is an ABC and we choose
  // the console-based UI here.

  r.add(
    r.type<StockQuoteApp>()
    .in_scope<di::scopes::singleton>() // The reason we can request a reference in the main function!
    );

  r.add(
    r.type<UserInterface>()
    .implementation<ConsoleInterface>()
    .in_scope<di::scopes::singleton>()
    );

  r.add(
    r.type<StockQuoteServiceFactory>()
    .implementation<StaticStockQuoteServiceFactory>()
    .in_scope<di::scopes::singleton>()
    );

  r.add(
    r.type<HttpDownloadService>()
    .implementation<AsioHttpDownloadService>()
    );

  r.add(
    r.type<boost::asio::io_service>()
    .in_scope<di::scopes::singleton>()
    );
}

As you can see, the mini-DSL (ugly, ugly, ugly, details) describes a few things:

Default implementations for various interface classes. See UserInterface and ConsoleInterface, for example.
Life-cycle management. Singleton is mostly used here but you can also have HTTP-session scopes, thread-local scopes or no scopes (as in HttpDownloadService).

What this means is wherever a type T with a DI_CONSTRUCTOR macro is registered, the registry will use these rules described by the DSL to construct any arguments to T.

Providers
In this library, there is a concept of a type called a provider whose sole responsibility it is to construct objects (usually within the constraints of a scope). In the app session above, I pointed out how the HTTP download service is not instantiated until it is actually needed. This is done via a provider. You can see the YahooStockQuoteService has a constructor which accepts a provider and a function which makes use of it.

That should be enough information to peruse the example itself. Check the README as there are a couple of interesting exercises you can try.

By the way, this requires a Boost checkout with a built version of Boost Build. I apologize if you can't get it to build on checkout, but I haven't really focused on having other people use it!

Comments and thoughts welcome.

C++ has not jumped the shark

noreply@blogger.com (Unknown) — Tue, 29 Mar 2011 15:55:00 +0000

I love John's blog. If you are not subscribed, you should be subscribed. He is one of my favourite bloggers as I actually learn something when he posts.

Somehow, I managed to miss his post on C++ going about as far as it can go in its evolution. Fortunately, it showed up on YCombinator News a few days back so I got the chance to catch up.

From my reading, John is concerned about the following:

The language has stopped evolving because it is too long between revisions of the standard.
He doesn't need anything new therefore new features are not useful for him.
Something about concepts.

I don't intend on refuting or accepting those points as that's not what this is about. I just wanted to give a short summary. Also, I'm not really that interested in concepts but that is no reason to not include them. I'm sure I would also have said "TEMPLATES? WHY DO WE NEED THIS COMPLEXITY?!!!!"

The current C++ standard has been greatly influenced by the various Boost libraries. From lambda to thread, the influence of the Boost development experience is obvious, if not prevalent. Boost made it easy to decide what libraries to include. After all, we've had a few years of practical experience with them.

Reading the list of libraries in first-released order, there are a lot of libraries for various holes in the standard library. The Wikipedia article on the Boost libraries makes it much more clear as to where Boost development has been focused.

There is another trend: the number of libraries dealing with language issues has steadily decreased over time. Now, that is not to say that there will not be another set of C++0B libraries, there probably will. But I don't know if it will trigger the same kind of innovation.

So if that is all true, is C++ over?

In the last few years, there has been a gigantic evolution in C++-land: Clang. I have been fortunate enough to spend some quality time with Clang in the last little while and I have to say that I have enjoyed it a lot more than the last time I spent some time with another open-source C++ compiler.

With Clang, it is reasonably easy to add new features, even easier to add features that translate into combinations of existing features.

So while it was straightforward to add library changes to C++0B due to Boost, it was a lot harder to do the same for language syntax because there was no real experience with many of the proposed features.

Clang can enable, for the language, what Boost enabled for libraries.

However, I don't think Clang is really at the point from an organizational and technical perspective where it can enable and manage the kind of innovation that Boost was able to oversee.

That being said, I look forward to its role in the future of C++. I think it's a bright one*.

* Someone please make C++0B lambda polymorphic.

Continuous testing with Emacs

noreply@blogger.com (Unknown) — Sun, 15 Aug 2010 18:32:00 +0000

The other day, I came across a very interesting paper on continuous testing during development. In it, the authors found that program correctness for a group of students could be predicted based on whether the students used continuous or manual testing. Continuous testing is running your compilation and project tests as you save files locally, as opposed to continuous integration which usually works as you check in code. Manual testing is having the student run the test suite manually. Those students who used continuous testing were a few times more likely to finish the project and had less mistakes.

There is nothing in Emacs preventing a developer for implementing this behaviour for their projects so I decided to do that to simplify the edit-test cycle for a particular project.

The key is that after saving a file, using the built-in Emacs hooks, I launch a compile process. The hook only does so if the file being saved is located in the project directory by looking for a string in the filename, "tmp" in this case.

Here is a screencast of the behaviour with the code in the left side of the split. In the right split, I am editing a script (/tmp/runtest) which represents the test suite. The "project" is located in /tmp. The video shows me saving the test suite file twice. Once with no errors and the second time with an error. In the first case, the compilation buffer goes away once the test suite has run, which keeps things tidy. In the second case, the compilation buffer stays around because an error occurred in the "test suite".

This specific setup works best with a compilation and test phase which runs relatively fast. To make it work for longer test suites, you'd need to probably modify the test-command code to kill the compilation first. You'd probably also want to modify the after-save-hook to use some kind of timer after which you start the compile.

There are lots of things which I'd like to work better, but it works OK for me now.

Let me know how it works out for you if you try it out. The code is here.

Enjoy!

Dependency Injection in C++/Plugin-based C++ applications

noreply@blogger.com (Unknown) — Sat, 22 May 2010 18:22:00 +0000

I have made two of my coding research projects available on bitbucket. One is an example of writing a C++ application which can dynamically load and execute Python plugins and the other is an investigation into a Google Guice inspired dependency injection library in C++.

See the wikis for some explanation and browse the code. The code is under WTFPL.

If you're wondering, I chose Mercurial because I do not have the brain capacity to understand Git.

Using Boost Build on your own projects

noreply@blogger.com (Unknown) — Mon, 21 Dec 2009 01:13:00 +0000

While I am a fan of SCons, every now and then I like to dabble in other build systems. One that has intrigued me for some time is Boost Build (BB). You can visit the linked site to find out more about it but in a nutshell, it is a very elegant way to build C++ software.

This post will attempt to give you some steps you can use to get started using the tool on your own projects. Note that it is a bit long but if you are new to Boost Jam as I was a few weeks back, I think it might help you get started. Please feel free to ask any clarifying questions in the comments.

In the following Boost Jam is the build tool and Boost Build is the library on top of the Jam language. I use them interchangeably, and I'm sure people will give me hell for it.

Building Boost Jam

Before getting started, I suggest you build Boost Jam as follows (might as well get Boost too!). I assume you are on a Unix system ~~because there really is no reason to use Windows anymore ;-)~~ but you should be able to get the same results on Windows with some slight modifications.

$ wget http://downloads.sourceforge.net/project/boost/boost/1.41.0/boost_1_41_0.tar.bz2
$ tar -xjf boost_1_41_0.tar.bz2
$ pushd boost_1_41_0
$ export BOOST_ROOT=$PWD
$ pushd tools/jam/src/
$ ./build.sh
$ export PATH=$PWD/bin.macosxx86:$PATH # substitute appropriately

Now, when you type "bjam" at the command prompt, you may get the following output:

$ bjam
warning: No toolsets are configured.
warning: Configuring default toolset "gcc".
warning: If the default is wrong, your build may not work correctly.
warning: Use the "toolset=xxxxx" option to override our guess.
warning: For more configuration options, please consult
warning: http://boost.org/boost-build2/doc/html/bbv2/advanced/configuration.html

error: error: no Jamfile in current directory found, and no target references specified.

The Jam Language

One complaint about Boost Build is that we must use the Jam language. However, it's really not so bad. While I would prefer Python, the Jam language is consistent and very simple. The main things to remember (this is my mental model and may not be technically accurate):

Rules are the same as functions in other languages

Parameters to functions are separated by ":"

All tokens are white space separated (use quotes to embed white space)

Results of functions can be used by enclosing the function call in a [] pair

Comments start with # and go to the end of the line

Here is an extremely simple example of a rule/function (create a file called "Jamroot" in the current directory and put in the following):

rule show-list ( list-of-stuff + : sep ) #1
{
    for local l in $(list-of-stuff) #2
    {
        echo $(l) $(sep) ; #3
    }
    return "Hello, World" ;
}

echo [ show-list 1 2 3 : "|" ] ; #4

This line declares a new rule called "show-list" which accepts two parameters: a list as the first parameter and a single value as the second. Note the "+" modifier on the first parameter. This indicates to the build tool that at least one parameter is expected. You can use "*" to indicate 0 or more. I believe this can also be used to indicate optional parameters

This line is a for loop using a local variable. Note the variable expansion using the "$()" syntax. In this case, each iteration of the loop will expand to an element of the list in list-of-stuff.

Here we call the echo rule. Note that the line is terminated by the ";" symbol. This is required!

Finally, we call the new rule with a list as the first parameter and a keyword enclosed in quotes as the second parameter. We use the result of that rule and pass it to echo.

If you execute "bjam", the output looks something like:

1 |
2 |
3 |
Hello, World

Pretty boring!

Creating a new project

When Boost Jam is invoked, it looks for a file called "Jamroot" in the current directory or in one of the parents of the current directory. This is where you define project global settings. Let's do that now. Create a new file called Jamroot and include the following contents:

import toolset ;

project app
  : requirements
    <threading>multi
    <link>static
    <warnings>all
    <warnings-as-errors>on
    # Equivalent to <toolset>darwin: <architecture>x86 <toolset>darwin: <address-model>32
    [ conditional <toolset>darwin: <architecture>x86 <address-model>32 ]

  : default-build debug release
  : build-dir build
;

The requirements state that all artifacts should be built using multi-threaded libraries, built statically with all warnings and all errors. Additionally, on darwin, we only want to build 32-bit executables for the x86 architecture.

In the default build (when you type just bjam), both debug and release variants will be built and put into the build directory relative to the Jamroot.

Now, type "bjam". If you are on OSX, you may see something like the following:

$ bjam
warning: No toolsets are configured.
warning: Configuring default toolset "gcc".
warning: If the default is wrong, your build may not work correctly.
warning: Use the "toolset=xxxxx" option to override our guess.
warning: For more configuration options, please consult
warning: http://boost.org/boost-build2/doc/html/bbv2/advanced/configuration.html
...found 1 target...

The reason for this is that BB guesses the toolset but on OSX we should really be using the darwin toolset. When Boost Jam starts up, it looks at ~/user-config.jam (somewhere similar on Windows) for a user configuration file. Add one with the following contents:

# ~/user-config.jam
using darwin ;

Now when you hit bjam, you should see something like:

$ bjam
...found 1 target...

Alternatively, if you don't want to pollute your file system, you can execute:

$ bjam toolset=darwin
...found 1 target...

Adding a project target

Now we will add a simple executable that links to some Boost libraries. Create a directory named "app" in your current directory and create a file in this directory named "Jamfile" with the following contents:

# app/Jamfile
exe app : [ glob *.cpp ] ;

Additionally, create a C++ file in the app directory with a trivial main function and the ".cpp" extension. Execute bjam. Nothing changed! That's because we haven't asked BJam to build our project. Try executing "bjam app". You should see something like the following:

$ bjam toolset=darwin app
...found 20 targets...
...updating 17 targets...
common.mkdir build
common.mkdir build/app
common.mkdir build/app/darwin-4.0.1
....
darwin.compile.c++ build/app/darwin-4.0.1/debug/address-model-32/architecture-x86/link-static/threading-multi/main.o
darwin.link build/app/darwin-4.0.1/debug/address-model-32/architecture-x86/link-static/threading-multi/app
common.mkdir build/app/darwin-4.0.1/release
...
darwin.compile.c++ build/app/darwin-4.0.1/release/address-model-32/architecture-x86/link-static/threading-multi/main.o
darwin.link build/app/darwin-4.0.1/release/address-model-32/architecture-x86/link-static/threading-multi/app
...updated 17 targets...

Note that both debug and release builds were created with one invocation. To restrict to one or the other, execute "bjam variant=debug" or "bjam variant=release".

Using Boost

Remember when we downloaded Boost? Now we will use it! The mechanism for using another Boost Jam project is the "use-project" rule. Add the following to your Jamroot file:

use-project /boost : ../boost_1_41_0 ;
alias boost_thread
: /boost/thread//boost_thread
: <warnings-as-errors>>off # bunch of warnings

Here we told the build system where the project with the id "/boost" is located. In this case, it is ../boost_1_41_0, relative to the Jamroot file. Yours might be different. Additionally, we added an alias for the Boost thread library. The main reason for this is that a single alias reduces proliferation of any special handling needed.

If you type "bjam" now, you will not be surprised that nothing is being built. Let's fix that now. Add the following to the Jamroot file:

build-project app ;

Now, whenever you invoke bjam, the app project will always be built. Invoke bjam now. You should notice that Boost thread is not being built. Again, this is not surprising. We aren't using it anywhere! Modify app/Jamfile to look like the following and execute bjam:

exe app : [ glob *.cpp ] ..//boost_thread ;

You will notice that Boost thread is being built in the Boost directory. This is not very useful as build artifacts are spread all over your disk. (Un?)Fortunately, there is a hack to making this work. Create a new file at the level of your Jamroot named "boost-build.jam". Fill it with the following contents:

# Add --build-dir to command line so that boost Jamfiles pick it up and use this directory to build.

ARGV += --build-dir=build ;

BOOST_ROOT = vendor/boost ;
BOOST_BUILD = $(BOOST_ROOT)/tools/build/v2 ;
boost-build $(BOOST_BUILD) ;

Boost Build looks for this file when building Boost (I think) so here we add the --build-dir parameter so that when building boost, it will build to our build directory. That's a lotta building ;-)

Hit "bjam" now. You should see Boost thread being built statically in the build directory now, in both debug and release variants.

Conclusion

In this post, you learned how to build Boost Jam, a little bit about the Jam language and created a simple project utilizing the Boost libraries. Next time, I will build on this post to cover making a plugin-aware C++ application (this is really quite exciting for me!) Again, if you have any question or comments, feel free to leave them below.

Knowing when to quit

noreply@blogger.com (Unknown) — Sun, 29 Nov 2009 20:37:00 +0000

"Crossing the Chasm" and "The Dip" are both great books which talk about a distinguishable lag between when early adopters and the bulk of your target market start paying attention to you, financially anyway.

There is a problem though: a failure and such a chasm look exactly the same for a fairly long time.

I think a second problem which I'm not sure any book really addresses is that some think they are in a dip when in fact they never entered a dip to begin with. That is why you hear things like "You can't give up now, you made $200!" because they assume that every market is infinitely sized and you've just got to keep going!

I read somewhere that the average annual sales for shareware is $400. Enough of those and the payment processor is doing alright but of course the authors are not. Classic case of middle-man makes the most money in a transaction.

So if you are one of those $400/year authors and you need to spend more than 2 hours a year on maintenance, I would really think that is a good reason to quit and do something else. You're not going to miss the $400. You never entered a dip.

There is a very popular and article titled Shareware Amateurs vs Shareware Professionals. I highly recommend a read. Almost as a case-in-point, the author of that article has quit software altogether and is a fairly successful blogger. That is knowing when to quit.

If you have to quit, which I do advocate in the right circumstances, it does not mean you are giving up. You are just going to keep trying until you hit your mark. And for heaven's sake, don't think of yourself as a failure. A failure is someone who never tries.

What do you think?

Using Boost Function with Qt, Part 2.

noreply@blogger.com (Unknown) — Sat, 17 Oct 2009 14:09:00 +0000

[Following up this post]

Johan asks:

please, please post that follow-up. I'm new to Qt and have just run into this problem. While searching the net, I think your solution seems like the best approach!

Who am I to deny a seeker of knowledge? Having used this method in a couple of projects now, I think it is fairly sound and easy to maintain. So here goes.
The main problem with the solution outlined in the earlier post was that it could not handle multiple arguments. On that same post, Ken posted his solution apparently inspired by mine. His solution also handles multiple arguments but does it by implementing qt_metacall, i.e., mimicking moc. This is probably the most scalable solution and I'll probably give it a second look when I need to do this again. The only problem might be requiring exact matches for types but I am not sure how much of an issue this is for code I have written.

To review, the problem is that we want to use function objects (Boost Bind, Boost Function, etc) as Qt slots because sometimes it is too much work to create stateful slots.

My solution looked something like this:


struct SignalHandler0 : QObject
{
private:
Q_OBJECT
public:
SignalHandler0(QObject * parent,
              boost::function const & f):
 QObject(parent), // parent will delete this object when destructed
 m_f(f) {}

public slots:
void
handleSignal()
{
 try
 {
   m_f();
 }
 catch(...)
 {
   // Cannot throw exceptions from signals.
   ASSERT_BUG_HERE
 }
}
private:
boost::function m_f;
};

bool
connect(QObject * sender, const char * signal,
     boost::function const & f)
{
return QObject::connect(sender,signal,
                       // Note: Not a leak as sender will delete the handler when destructed
                       new SignalHandler0(sender,f),SLOT(handleSignal()));
}

To extend it to a single argument, we might do:

struct SignalHandler1 : QObject
{
private:
Q_OBJECT
public:
SignalHandler1(QObject * parent,
              boost::function const & f):
 QObject(parent), // parent will delete this object when destructed
 m_f(f) {}

public slots:
void
handleSignal(QString const & a)
{
 try
 {
   m_f(a);
 }
 catch(...)
 {
   // Cannot throw exceptions from signals.
   ASSERT_BUG_HERE
 }
}
private:
boost::function m_f;
};

That is, create a new class with the right signature. So you might think: well that screams for class templates! Unfortunately, Qt does not support class templates. Doh.

So basically, we write it out:


struct SignalHandler : public QObject
{
template
SignalHandler(QObject * parent,boost::function f):
 QObject(parent),
 m_handler(new SignalHandlerImpl(f))
{}

struct SignalHandlerBase
{
 virtual ~SignalHandlerBase();
}

template 
struct SignalHandlerImpl
{
 SignalHandlerImpl(boost::function f):m_f(f){}
 boost::function f;
}
public slots:
void handleSignal(void);
void handleSignal(QString const &);
...

private:
shared_ptr m_handler;
};

void
SignalHandler::handleSignal(void)
{
typename SignalHandlerImpl type;
type* handler = dynamic_cast;(m_handler.get());
ASSERT(handler);
handler->f();
}

void
SignalHandler::handleSignal(QString const & a)
{
typename SignalHandlerImpl type;
type* handler = dynamic_cast(m_handler.get());
ASSERT(handler);
handler->f(a);
}

You can use macros to generate these handlers. You will also need overloaded connect() functions:

template
QObject*
connect(QObject * sender,
     const char * signal,
     boost::function slot);

...
template<>
QObject*
connect(QObject * sender,
                  const char * signal,
                  boost::function slot);

template<>
QObject*
connect(QObject * sender,
                            const char * signal,
                            boost::function slot);

Again, you can use macros.

I prefer Ken's solution from a technical standpoint. It is a good evolution. The main advantage of his solution is that the amount of code you need to add scales linearly with the number of arguments you need to handle whereas with my solution, they scale with the number of signals and that there are no macros.

The main advantage of my solution is that it is simpler to understand and maintain, which might be worth the extra code.

Hope that helps!

The best market is one with lots of money

noreply@blogger.com (Unknown) — Wed, 19 Aug 2009 05:04:00 +0000

There are always people who feel that developing plug-ins is not a profitable market. Now while developing a plug-in may not make you as rich as Bill Gates, if there is a sizable market, you will make money.

So if you are looking for whether your idea makes sense, here is a simple relation to figure it out:

UnitPrice * NumberOfQualifiedCustomers * ConversionRate >= SomeSpecificFinancialGoal

If the statement is true, you will make money. If it is not, you will fail.

I'm pretty sure that I grossly over estimated NumberOfQualifiedCustomers when creating Worklog Assistant. How did I over calculate? Simply, the number of total JIRA users who also use JIRA as a timesheet system is quite small (yeah, duh right?) I would not have known this if I did not reach market quickly.

However, I used very pessimistic values for ConversionRate so maybe that balanced it out because I still reached my financial goals.

What does this mean for me? It means V2 is going to kick some serious ass. Oh how I wish I could have people to work on this with me, wink wink :-)

Going AFK with Bazaar

noreply@blogger.com (Unknown) — Thu, 09 Jul 2009 21:12:00 +0000

One thing I've really liked about distributed VC systems is that they handle merging really well. Of course, this is not limited to DVCSs. Subversion and Perforce have very good merging but do not support offline work very well.

I've been using Bazaar for a little while now for my app because I knew that I would need to be offline every now and then. I just had one of those periods and thought it would be a great chance to see how well AFK mode works with Bazaar.

This is more for my own future reference rather than for you :-)

laptop $ rsync -avz -e ssh sohail@desktop:/home/sohail/bzr/ ~/bzr
laptop $ bzr branch ~/bzr/code/master project
laptop $ bzr bind ~/bzr/code/master

Now I can work offline in the "project" directory and all checkins go to ~/bzr .

Upon return:

laptop $ rsync -avz -e ssh ~/bzr/ sohail@desktop:/home/sohail/bzr

NOTE TRAILING SLASH ON SOURCE DIRECTORY!!!!!1111oneone....

Note: I think the above is insane. Ideally, I'd just do something like:

laptop $ bzr checkout bzr+ssh://sohail@desktop/home/sohail/bzr bzr
laptop $ cd bzr
laptop $ bzr work-offline

Return from afk:

laptop $ bzr I'm back

Or something like that.

VanCPP June meeting

noreply@blogger.com (Unknown) — Mon, 08 Jun 2009 23:37:00 +0000

If you are in Vancouver and interested in programming (who isn't?!) you might want to make your way to the VanCPP meeting in June. The announcement is below:

Our June 2009 meeting will be held on Thursday, June 18. Please note the new venue.

Topic: Concurrent Programming in the D Programming Language

Presented by Walter Bright

Abstract: Many-core concurrent programming offers exciting and compelling advantages. The single core, single thread programming model is assumed by imperative programming languages. This model offers sequential consistency as its fundamental characteristic.Because many-core systems use layered cache memory systems,sequential consistency is not guaranteed among threads.Because imperative programming languages allow implicit sharing of data between threads, many misguided idioms and optimizations are possible that erroneously assume sequential consistency.One example of this is the double checked locking optimization.The pernicious nature of these sorts of bugs is they defy programmers' natural intuition about how programs behave,they are not statically detectable, and there is no way to reliably test a program to rule out the existence of such bugs.A program may appear to work, but have problems appear years later, fail when ported to a different platform, and such problems may be extremely hard to reproduce and track down.In essence, the correctness of the program relies entirely on the expertise and care of the programmer.This is not an acceptable situation for developers of programs that require high reliability.

The D programming language is an imperative programming language with an innovative type system that prevents implicit sharing and also fosters a complete, integrated pure functional subset. It is possible to statically verify that D programs do not have sequential consistency bugs. The double checked locking optimization bug is not possible. Type support for shared data and immutable data, as well as pure functions, means that mutating data interactions between threads can occur only under carefully controlled conditions.This dramatically reduces the problem space for concurrency bugs from the whole of the source code to a small subset of it, making it a much more tractable problem.

Speaker bio: Walter Bright graduated from Caltech in 1979 with a degree in mechanical engineering. He worked for Boeing for three years on the development of the 757 stabilizer trim system. He then switched to writing software, in particular compilers, and has been writing them ever since.

The meeting will be held at:
Workspace
21 Water Street
Vancouver, BC
V6B 1A

Regards,

Vladan Vidakovic