I really enjoyed this Ease at Work presentation. I could've used it when he gave it in May of 06 when I was in the middle of a gig from hell that did a number on me. But, I do identify with so much of what Kent says.

Seems like we're about the same age, I'm 50 and guessing he's closing in, and we're both coming to a place of being tired of riding the genius, shithead roller coaster. This is where we are wasting a lot of time on being fucked up how good or not good we are as programmers. How some days we just feel so great only to be crushed by our total ineptitue the next day.

This manic and painful way of being is just so wearing and wasteful. Kent guesses that it may have something to do with our age and how this technology was kind of a novel thing when we were growing up. And that we may have gotten our sense of worth from being these kinds of wizards that make these magical boxes spin. He says that it may be that younger people take this stuff as just ordinary parts of their life. Would be like I got all puffed up about being the guy that can fix the frig and all you lesser intellilects would never have the skills or magic to do that.

I mean, just how much time have I wasted on riding this pendulum? And it just seems that this bipolar view of oneself in relation to one's craft, or just plain work, is pretty dysfunctional.

This view of oneself also promotes an otherness and entitlement that must be annoying to be around. Why do I feel that I should be exempt form the constraints within the company I work for?

Do they not know that wizard are to be revered and should not be tied to the mundane reality of limited resources or limited timelines?

Stole that title from this, Accountable for production not attendance. Jeffrey Phillips makes an excellent point out of how the factory, three shift based work schedule was created to get a good ROI from expensive manufacturing machinery. This type of way of working really doesn't apply to software development or many other types of work.

For me, it just doesn't make sense to adhere to this way of working. And I've found that I'm just so much more productive on my couch with my Mac.

At home I can:
• work when I'm in the zone
• limit context switchs, or at least control what context to switch to.
• not WASTE hours in traffic every day
• use my preferred tools and development environment, mac, emacs, IDE's ...
• not play the odds on the roads, scary seeing the car wrecks everyday

And at home the DO/TALK ratio is so much higher. I've been in so many environments where this is so little DO, but an over abundance of talk. And there is so much more talk required where people aggregate, like at work. Just so much smoozing, chit-chat and social lubrication going on. Which is OK and fun sometimes but such a productivity killer.

Oh,and it's really hard to get into long winded conversations about the way things can and cannot possibly work when I'm on my couch. I usually just fire it up and give it a shot.

About the only negative point about working on my couch is that I don't get in front of a white board with someone to verbalize and grok an idea. But, I can get that at a hackfest, user's group, or some other geek event.

There are some pretty funky workarounds for scaling apps to multiple JEE app servers. Here’s a good description of the problems. Session State is Evil by a Java guy.

I've been a long time user of Emacs, even during my J2EE days. I even use those funky emacs keys in firefox. And I guessed I missed the whole Emacs/Ruby/Rails discussion at RubyConf. But I got interested when I talked to Aaron Bedra about how he's doing remote pair programming.

Don't know how I missed GNU Screen? I've always started up emacs to give me multiple shells and now I'm going to start playing with Screen.

Anyways, here are a couple of links to get me started.

• Remote Pair Programming I really like this guy's blog for emacs/ruby/rails stuff.
• The whole suite that EdgeCase uses. Blogged about by Joe O'Brien
• A very cool whiteboard application, LauchPage, that can be shared remotely.

Now, I do like TextMate and I have used it, although half-heartedly, but I prefer Emacs because:

• it works on multiple platforms (Mac/Linux/Windows)
• allows me to switch to Ruby, Java, C, C++, ... without changing my dev environment
• provides just such a rich dev environment (ECB, Flymake, ...) and set of utilities.
• is so extremely extensible, configurable, ...
• has pretty decent Rails environment.
• And, probably most significantly, my fingers just go to those Emacs key-combos automatically after 20 years of usage.

Oh, check out the eigenclass blog for his emacs goodies.

Got to check out how Ryan Davis is using Emacs with Rails. Gotta listen to this Rails Podcast

Stefan Tilkov's gave a great talk on the REST vs SOAP debate. He clarified the terms and focused on comparing "Technical SOA" vs REST architectures. He then took a swing at WS-*

• Video
• Presentation

Some interesting quotes:

“No matter how hard I try, I still think the WS-* stack is bloated, opaque, and insanely complex. I think it is going to be hard to understand, hard to implement, hard to interoperate, and hard to secure.”
Tim Bray, XML Co-inventor

“Show me the interoperable, full and free implementations of WS-* in Python, Perl, Ruby and PHP. You won’t see them, because there’s no intrinsic value in WS-* unless you’re trying to suck money out of your customers. Its complexity serves as a barrier to entry at the same time that it creates ‘value’ that can be sold.”
Mark Nottingham, ex BEA, now Yahoo!, former WS-Addressing WG Chair

If you’re ready for REST I suggest you jump on board right away and get ahead of the curve [...] You’ll have to train your developers in REST principles. [...] You definitely need to provide guidance to your people. What you want to do is work to the point where REST becomes the default for all your distributed applications.
Anne Thomas Manes, Burton Group

Yep.

“Want to be cool? Learn REST. Want a career? Learn WS.”
Steve Jones, Cap Gemini

Should be "What a job now? Learn WS". Want a job or career in the future? Learn REST"

Notes on the Context, Perspective and Programs talk at OOPLSA 07

• Gregor Kiczale
• Podcast/MP3MP3
• Presentation
• Mylyn
  • task focused UI for Eclipse. Save the context for a particular task. Integrating repositories like Bugzilla, Trac and JIRA and a set of other artifacts, set of files, into a context.
  • Lightweight management of higher level tasks
  • Like a changeset. Wondering how git lightweight branches code be part of a context/task? What's the cost of managing this higher level context, how much effort?
• Some of the GOF created a tool for generating code from a selected pattern
  • Found that the tool was inflexible.
  • That Pattern are frequently modified within a given development context
  • Best part of the tool was HTML docs that linked the pattern references together
• Programming Languages
  • The world isn't formal. But, software/PL is.
  • Languages are very concrete, formal, "effectively formality"
  • Design Patterns are not. The are subject to social, tech and other aspects of the context.
  • Design patterns are not effective, in this definition, because if you change a Design Pattern not all of the implementations in the world will change automatically.
• Lucy Suchman
  • There is not an objective social model of the world.
  • Situational particulars determine meaning between people.
  • Expressions that rely on their situation for significance are commonly called indexical. Examples: that, nice, ... are words that have meaning when people are communicating. But they have meaning in context, in the embedding world.
  • People never understand each other preciously, it wouldn't be possible, it's ok.
• Brian Cantwell Smith - Origins of Objects.
  • Intentionality is ability to have aboutness.
  • The world is sloppy.
  • The idea of Objects without context is just not right
  • “The world is as opposite of formal as it is possible to imagine”
  • no single right structure, or even ontology
  • abstractions are transient, shifting, negotiated
  • things are not formal at the bottom
  • “ they know what they are talking about in that way”
  • actions, including plan production are situated
  • objectivity is achieved rather than given, all language is indexical
  • things are not formal at the top
• Formality is NOT the right mechanism. Effectiveness has to be more sloppy. Effective is the ability to generate a concrete thing.
• Registration is the ability to map the intentional, patterns, to the effective/formal.
• Example of registration in Emacs; Emacs derives much of its power from supporting multiple simultaneous “takes” on the string of characters in its buffer, in just the way suggested here.
• Registration is the binding btw the abstract and the concreted/effective.
• Mapping btw patterns, which are sloppy, and program, which is effective.
• Mappings must be done by a human because they know context?
• AOP may be a way to map/register btw a natural language text and program code using a Fluid aspect.

Eric Evans, DDD putting the model to work

• Shipping Domain as an example.
  • Cargo has a origin, destination,.., arrival time.
  • Cargo is fed into a Routing Service, SOA, that populates a DB table
  • DB table has rows for each stop in the voyage.
  • Problem with this design is that a great deal of the Domain is missing from this design.
  • Let's identify the terms in the Domain. Get in the room with a Domain expert.
  • Domain expert may not know what you're asking for. Have to encourage/invite the Domain Expert to give you the info. Possibly introduce you're own definitions and have them confirm.
  • How do you interact with the Domain/Business person?
  • Go in with a propoisal. Cargo has many "stops" in it's iterany. Cargo has many "legs". Really the same kind of thing, legs and stops.
  • Notice that the word Itinerary is used. This may be Domain Entity
  • How to choose btw stops and legs?
  • Using both introduces more complexity than needed.
  • Little sidetrack into defining some DDD terms.
  • Model. A system of abstractions that describes selected aspects of a domain and be used to solve problems related to that domain.
  • Using Maps as an example of a Model. Show's example of maps of locations, include the earth.
  • On global Mercator map Greenland is seen as very big. Why?
  • Because the Mercator map is used for sea navigation. Don't care, so much, about the size of land masses.
  • Model in NOT as realistic as possible.
  • Allows software to enter the domain.
  • A model not reflected in the code is irrelevant
  • Back to the question, use stops or legs?
  • No enough info to make this choice.
  • Let's get a concrete scenario. Show's booking cargo from Hong Kong to Seattle via Long Beach.
  • Developers need to remember is that they are not the domain experts and they have quite a lack of knowledge of the Domain.
  • Developers should NOT make Domain Experts play by their technical agenda. Domain Experts will, usually, have a good business reason for asking for something.
  • The scenario of cancelling and rerouting this shipment during transit makes it clear that we shoudl use leg. Leg is used by domain expert in describing the process.
  • By feeding the Cargo into the Routing Service we get an Itinerary. Which is made up of N legs.
  • If Eric presented us with a different concrete scenario we may have choosen stop instead of leg. For example, if the scenario had to do with unloading the cargo at a port.
  • So, there are many different models that we could've choose going done a different concrete scenario.

• Leaky abstractions. Need to know what's going underneath abstractions sometimes. Knowing what SQL is generated by ActiveRecord
• Orchestrate Business Objects/Models in Controllers. Don't need Something.find(...:conditions ...) in the controller. Create a method on the model that abstract the condition and is a better domain name or business term. Post.find(....) to Post.recent
• Be militant about MVC. Keep business logic, database query find(...:conditions..) out of controllers.
• Don't do bare model finds. Use a object that is created at all entry points. User.posts.recent instead of Post.recent( ...:conditons => user_id = user.id) . Anything the user/account has access to can be reached from that account object.
• Add methods to Association Proxy. Association Proxy is how model associations are implemented. You can add methods to these proxies doing has_many :posts do self.recent { ...} end This will add a recent method the posts association proxy. Associaton Proxies
• Favor before filters to get instances needed in controllers. Example: Post.find(param(post_id)) at the start of all actions. Find the post in a before filter instead of writing code to find it at the beginning of every action.