so cool, des ne?!

hey! shove scala up yer nose, care of GAE.

remind me to get off my ass and set up a TOR node.

oh, sure, you are very objective, no problem. aren't we all.

some core thoughts on how trust can and should work in business.

ugh. technology sucks. technology is hard. people suck. we're all such cheap-asses.

i mean, come on, does anybody really need any further justification for legalizing it?!

so who is going to make the remake of the Thriller video with an actually post-moribund MJ?

pick limitations, stick to them, execute really well out of the gate.

oh, noes! we forgot about software engineering! (yes, i live in a glass house.)

so, i'm really starting to believe in something like Clojure, but only if i could have something like Dialyzer for it. so, really, i'm thinking that i should just be using Erlang (with LfE). w00t.

[blogger: wow, we utterly failed to post that, charlie, maybe you should tell us what you were trying to do, since our system is such a turd it doesn't even know what you were trying to do when we utterly failed to do what it was you wanted to have done.]

wow.

i'm really not enjoying the effing advertisements blogger is showing me when i post things.

i mean, i guess they figure "so much for text ads, let us do the really annoying graphical ads just like everybody else, even though what got google the gold in the first place was the subtle approach."

money sucks.

i've complained before about how things like Eclipse go the wrong way about it when it comes to setting up code formatting preferences. yeah, it still bugs me. no, i don't have the resources to pony up an implementation of a solution. so i suck.

i <heart> how Eclipse manages to keep some little totally fubar user interface things around so that i can stumble across them just when i've sorta gotten to an ebb in my frustration and hate of it all. like: cutting text out of the Find/Replace's "Find:" text field doesn't actually store that cut text in the clipboard. no, the previous clipboard text is still there. wtf?!

somebody reminded me, i need to learn me some J some day. in my copious free time.

wow, go oracle!

does your kanban board have a swim lane entitled "respect for others"? maybe it should, lest people forget...

hm, another set of quite interesting better abstractions. i especially like the thoughts about deterministic concurrency.

why, in this new bloody millennium, are there so many people, even supposedly computer professional types, who have no freaking clue about editing down messages they are replying to? it kills me!

twice in one week i came up against the "saving documents and editing and printing them is quite often a complete fuster cluck" experience. if there's a reason that the intelligent aliens are staying the heck away from us, it is probably something like our utter failures in usability like that.

yeah, yeah, the open-closed principle is this great wonderful thing we should all follow to a t. except for how then you get a zillion files with all sorts of annoying "extends this" and "implements that" and "noSuchMethod" etc. etc. so that it is really bloody difficult to see wtf is actually going on. edit the original files, i say! (of course, this would be best done in the context of having good testing coverage.)

i, for one, totally geek out on diagramming. and how.

"Any captive children on-screen at the time Dance Magic is activated are not harmed."

"Bubbles: Part of the peculiarity of this game comes from this unusual power-up. Bubbles the chimpanzee, Michael's real-life pet, appears in each level. Once collected or rescued, the chimp transforms Michael into a robotic version of the pop singer that has the ability to shoot laser bursts and absorb significantly more damage."

nifty: encapsulation theory.

hmmm, another group where i'd kill 'em and eat their brains in envy.

how can anybody still use a language that has the moral equivalent of .h files?

i think i've heard that Mr. Kay says that OO was really about messaging. so i think that things like using an abstract class + child concrete classes to define a range of implementations for an API could instead be done by defining message contracts, and then having things which said they met that contract. point being that inheritance is more often than not a brittle and/or confusing thing in the long run.

if, like me, you love the idea of CTM, and even have a copy, but never find the time to read it, then check out the condensedish version.

respect, sheschmect. poop on 'em, i say! poop!

in the debate around how to use coding metrics, i fall on the side of trying to not use them as measurements of how well people are doing because that will run the risk of people gaming things.

but perhaps people should be happily set up by default to run metrics on their own, and maybe there should be a quarterly review of metrics overall just as a means of team feedback?

"[scala-user] "Double dispatch" issue of inherited trait method with sequence args when used from different package within a for comprehension"

perhaps there is something to be said for a non-statically-checked language because the implementation will be a lot simpler?

"Agile closely matches an explorative process. Dealing with uncertainty in terms of unknown unknowns.

CMMI clossely matches optimizing processes. Optimizing delivery of things "everybody" in the organisation knows very well or at least the experts in the organisation know very well.

Both are very important for most organisations. The latter is often called "bread and butter" the former is called innovation."

real options: reducing the cost of change; allowing you to change your mind.

reduce the cost of change: requires having good engineering so your system isn't brittle.

tdd is cool and all, but don't go overboard drinking the kool-aid.

it still pretty much gets me every time (specifically, around 0:42).

man, skynet will have nothing much left to do when it takes over.

any language with "yes, mutable" as the default is kinda wrong, imho.

1. Options have value.
2. Options expire.
3. Never commit early unless you know why.
4. An option's value increases with uncertainty.

in my dictatorship, all car turn signals would be orange, and all brake lights would be red. turn signals would never be the same color as the brake lights. furthermore, EL wire would be run along the length of the car to act as turn signal, so that you have less chance of 2 people trying to merge down into the same lane between them (which happened twice on my 20 min commute to work today).

so. why can't they just use phasers to shoot incoming photon torpedoes? i mean, if we can already do that kind of thing today...

"For both Motown and Pixar, the important aspects were getting the right teams in place - then creating a process which ensured each and every product received the attention of experts. If it didn’t meet expectations, it was sent back - as often as necessary."

"Don't work within the constraints, aim to remove them."

dood, new flash: cancer sucks.

it is amazing how msft comes up with these promotional videos for things like that song stuff and now natal that manage to be so stupendously badly cheesy and weird and painful.

"they do not have as much faith in their core product to explore and develop it to be better value"

1. Own the Vision and Release Backlog

2. Manage Release Content

3. Maintain the Product Roadmap

4. Build an Effective Product Manager/Product Owner Team

AAABBBCCC

vs.

ABCABCABC

as sundry people have been pointing out for a while now.

yup. still hate yahoo products.

and, good luck to all.

"I've even done "combative ping-pong" which can be a lot of fun. In this style, your objective is to write the least amount of code possible to get the test to pass. And I mean the least. Then write a valid failing test that forces your pair to do as much work as possible. We did this in a carousel once. I expected the end result to be a dirty mess, but the end result was a simple, functional design with clean code. And we had a lot of fun with it."

my kingdom for subtext 2.

i think any decent software development system (programming language + libraries) should support easily doing transactions within the code. so many things are transactional even in the small niggling parts of the system.

i kinda hate eclipse. sometimes. a lot.

today's reason (and of course no such reason is really just for one day) to <expletive> hate java: 'final'.

"At their heart actors are about distribution and concurrent interaction. Futures are about parallel processing. That's a gross over-generalization, but hopefully it helps people understand that there's no need to pound every problem into the actors framework."

'Having cut my teeth in Agile with XP many years ago, my experience of Kanban has been that people have begun to forget the basics already and are re-awaking an over-reliance on "process" (waterfall style) like we did in the past. This can be a distraction from focusing on what really matters which is invariably the team (people) and their abilities and interactions.'

best route to success: blame the user! blame the user!

some day when i have free spare cash, i'll start a company to produce vacuum cleaners that suck less (in the bad sense, they'd still suck in the good sense). i drives me bonkers that the people making things don't bother to design stuff to be, you know, actually user and use friendly.

"Technology is like an ill-tempered dog: never show it fear. If you are not sure how X works do not start inventing weird usage rules unrelated to how the technology works hoping they will somehow keep you safe. You will end up worrying a lot, not get the most out of your tool, and still get bit in the ass."

"Dependency injection is nothing more than the difference between this:

public class Bosh {
private final Dependency dep = new DependencyImpl();
}

and this:

public class Bosh {
private final Dependency dep;
public Bosh(Dependency dep) { this.dep = dep; }
}

In both cases Bosh needs a Dependency. It depends on having one. In the first case the actual implementation is hard coded. In the second the implementation is provided, or to put it another way, the dependency is injected."

"Dependency injection is nothing more than the difference between this:

public class Bosh {
private final Dependency dep = new DependencyImpl();
}

and this:

public class Bosh {
private final Dependency dep;
public Bosh(Dependency dep) { this.dep = dep; }
}

In both cases Bosh needs a Dependency. It depends on having one. In
the first case the actual implementation is hard coded. In the second
the implementation is provided, or to put it another way, the
dependency is injected."

it kinda seems like gmail is just falling apart. things i see, in multiple browsers:

* the buttons (report spam, delete, etc) at the top don't work. but the copy of those at the bottom do.

* the ajax version never finishes loading, and i have to use the standard html version.

* i go to label a message that has no labels, but the drop-down menu (the new version of which is a nightmare in and of itself) has some labels already checked!?

* don't get me started about the whole "you are working with a trashed conversation" ui that still <expletive>ing sucks.

still, all in all, i'm sure it is way better than anything yahoo! could either put together or buy.

wow. firefox sucks, but safari (at least 3.2) sucks a lot worse. impressively done, folks!

why does everything have to suck? take Safari, for example: it has the "i hilighted some text and now i'll right click and use the feature to use that text as a google search query" but, unlike Firefox, it doesn't put the search elsewhere. no, it replaces the current tab's contents. which is just plain stupid.

"Push means the planner is planning when things will happen. The planner determines when the worker is going to do the work. He therefore is telling (pushing) the work on the worker.

In pull, there is no planning by pre-cognitive means as in push. Instead, the worker decides when to do the work by pulling it off the list. When you have a smooth value stream, you get a high degree of predictivity by watching the rate of flow. While you aren’t telling people what to do, their stable flow rate gives you a predictive ability to see how much work you can get done."

"As an aside, the difference between push and pull can be very difficult to see from outside the system. The details are in the policies and behaviors, not entirely in how the work moves."

java: barf!

i.

hate.

subversion.

really!

word of the moment: transparency.

"When Python makes something look trivial, it's probably wrong."

neat: "men seeking 'interesting work rather than lucrative'" -- sounds like a good idea to me.

the fact that certain things even exist seems to me to be nice indictments of how humans create technology.

oh yeah, well, and besides that, there's the problem that people are also full of bad ideas.

"Most organizations are capable of generating more good ideas than they can hope to possibly carry out and if you try to do all of them you'll just fail at most of them, and even the ones that succeed will be slowed down because they weren't able to get the resources they needed and the people doing them spent a lot of their time dealing with other ideas that weren't as good."

"Most organizations are capable of generating more
good ideas than they can hope to possibly carry out and if you try to
do all of them you'll just fail at most of them, and even the ones
that succeed will be slowed down because they weren't able to get the
resources they needed and the people doing them spent a lot of their
time dealing with other ideas that weren't as good."

google maps is slow. really slow. even with the fast connection at work. so i give up and try yahoo maps.

talk. about. a. mistake.

totally re-affirms my belief that everything yahoo does is shit. with a big fat trade-marked exclamation at the end. shit!

"My idea at the moment is that there are 4 Primary Practices:
1. Visualise the Work
2. Limit WIP
3. Map the Value Stream
4. Measure the System"

[nobody suspects the spanish inquisition. #5: Improvement.]

why, oh why, don't people appreciate simplicity? like, i think people think they are doing more work or better work if the work is less simple. which! drives! me! totally! batty!

go read about Lean. about Kanban. please!

you have some code. ok, maybe you have a bunch of code. and, lucky you, you have a new feature to add. all i'm saying is: try to approach it by adding in whatever new use case concepts are needed, and map those down to the code, rather than sort of trying to work up from the code to the feature. off the cuff it might feel like the latter is more expedient, but it is pretty much a path to doom.

NPV vs. ROI, fight!

it is kinda funny how when code goes a certain direction, it becomes hard to go in a different direction. so a poor choice reinforces itself because it is harder to fix it than to just write more code in that style. w00t.

hey, i read it on the internet, it must be true. especially wikipedia!

nah, i'd definitely say that usability testing is over-rated. i mean, who has time or money for that?! just ship the damned thing! yeah!

here's an idea: how about you all grow the hell up, but noooo. shoot. i mean, what do the aliens think of us, with all these utterly same old same old crappy mostly naked pixel women games?!

it is nice to see the new at&t taking really good care of business.

"JSPG0036E: Failed to find resource /WEB-INF/pages/account/logout.jsp"

as. if. i'm. not. already. flooded.

somebody has to go and list more of 'em.

running a big ant thing with the output going to an Aquamacs compilation buffer is a gazillion times slower than doing it in a Terminal shell. even if you aren't watching the thing scroll, so it isn't just drawing to the screen that is slower.

even though java has a big ecosystem of possibly useful 3rd party libs, it blows my mind how often they are just dumb pieces of excrement. i mean, are there any logging systems for java that aren't just stupid wrong? i don't understand how programmers can develop these things. it is as if they never actually used the logging systems so that they never realized that the design was not really sufficiently useful for, you know, actually getting good results from the logging system.

""word

so something is considered to be hard. first off, with respect to the political situations, i think that is because the whole system is designed to put up too many grandiose laws. it is, after all, what keeps the politicians and lawyers in business, no? secondly, with respect to the programming question, i think there's this whole thing called "<expletive>ing agile" that might shed some light on how to deal with it all. but, heck, don't listen to me, i'm not a yegge. :-)

i would like to have time to muck with really relational data, since Date and Pascal bitch so much.

concision matters, dammit. (and, of course, the correct level of conciseness is context-dependent.)

i will always <heart> Dijkstra.

"We could, for instance, begin with cleaning up our language by no longer calling a bug a bug but by calling it an error. It is much more honest because it squarely puts the blame where it belongs, viz. with the programmer who made the error. The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation. The nice thing of this simple change of vocabulary is that it has such a profound effect: while, before, a program with only one bug used to be "almost correct", afterwards a program with an error is just "wrong" (because in error)."

"The optimal decision process is as follows:

* For each decision, identify the options available.
* Identify the last point at which a decision can be made. i.e. the conditions to be met to make a commitment. This is calculated by working out the deadline for the implementation of an option, and then working back to the decision point (i.e. the Takt time). The first decision is made when the first option expires.
* Until that expiry date, continue to look for new options.
* Attempt to push back the decision time. Quite often this is free or very low cost. To do this, we need to be able to implement the option as quickly as possible. During slack time, work on how to speed up the process (just like Toyota does in their production plant).
* Understand that cost optimisation is not the same as revenue optimisation or risk reduction. Sometimes it is worth investing in more than one option even though this may cost slightly more. After all, options have value (just ask Microsoft).
* Wait to make decisions... and wait... and wait... until the conditions are correct.
* When you need to make a commitment and act... do so as quickly as possible. And you can proceed with confidence because you know you have made the best informed decision possible."

"IMHO, trying to measure what is value is more difficult than trying to identify what is waste."

"It’s worse than the sound of your parachute failing to open."

heh, your tax dollars at work! (even for some people who aren't in the USA!)

now that is what i call awesome.

"...no longer feels himself to be freely active in any but his animal functions."

"A good job requires a field of action where you can put your best capacities to work and see an effect in the world."

ok, i really like how this sorting visualization is so different. nicely grounded.

nice oldie but goodie about api design.

i need to find time to really grok good functional programming style.

uh oh, haskell is hard.

like, and how!

generally speaking, i like the way they think!

'The ultimate goal is to deliver "marketable value" work as quickly as possible and "business value" work helps us get there effectively.'

(and don't forget "technical value", "human organization value", etc. all as part of the "business value".)

hah! visitor vs. functor, fight.

i do not like Groovy.

"* How classic "Big Noun" classes grew out of control and how moving to more role-centered abstractions has made the code easier to extend
* How badly expressed unit tests impaired progress and why I finally believe in BDD
* Creating an API that serves the end user instead of the internal model of the framework
* How our expectations for using a framework have changed very dramatically in the last 5 years
* The coding and design flaws that made the code harder to change"