Tuesday, May 31, 2011

What's with tryneat.com desk setup?

Every time I see the commercial for tryneat.com desk scanner, I lose it. Who sets up their desk like this?

Via tryneat.com.

This makes no functional sense. Why is the paper dumping towards the computer? Look how awkward the guy looks, his left elbow is going to bump the scanner. Look at all the open space on that nice wood desk, spread out! There isn't even a phone and the lamp is a mile away.

Where are the wires? They are not running away from the user, I think they are running inward to be hidden. That isn't realistic.

Bad form.

Wednesday, May 25, 2011

Standing desk

Over at Unplggd you can read all about the benefits and the cool ways to invent a standing desk for yourself. They've been talking it up on Twitter pretty good too.

So I went ahead and adopted this today to give it a try. It worked out good. Check out a real developer at his standing desk.


That's right, t-shirt, jeans, hair, barefoot and glasses. Pure developer.

Regardless of your occupation, give it a try. It's cool and good for you.

You need an extra monitor buddy, no I don't

Someone: You need an extra monitor buddy.
Me: No I don't.

Thoughts of technologist and software developers likely bring about office setups with many monitors. The thought is that the more screen, the more productivity. I used to be right there with everyone. Dual screens. Logs, emails, instant messaging, and monitors in one screen, development environment in another.

Then things changed... I was traveling a lot for work. All I had was my laptop, my nice Macbook Pro and I got used to not having a monitor. With six spaces and keyboard shortcuts, I've become more efficient without an additional monitor. I actually prefer it now. I never feel I need something else to be more productive. I also think it reduces distractions controlling focus of one screen at a time.

My desk also has more space for other items as well, or better yet, more of nothing. Some buddhas, a corded phone (yes, I don't like a cordless phone for work as it requires to be charged), a notepad, and a coaster for my coffee cup. Simplicity.


The above image is my actual desk. Nice huh.

I don't understand Facebook

Facebook confuses me.

I use Twitter and I don't have a Facebook. I used to have a Facebook back in the day when I was in college, like in 2004, 2005. When I graduated, I decided I didn't want Facebook anymore. When I was deleting my account, my reason (jokingly) "I've grown up". In all seriousness, I removed the account because I didn't want employers seeing the college version of myself.

Recently I went on Facebook via my wife's account and I didn't know what to do. There are too many things to do. There is an update feed and and a news feed, what's the difference? People can like status, and comment on the status? You can poke people, schedule events, execute applications, organize groups, apply privacy updates, etc. Status updates have embedded video, images and text. Status updates are long. Photo libraries and photo tagging? An inbox for messages? There is also instant messaging? Fan pages? Business page? Personal Pages?

I'd like to see the data model at Facebook.

I also noticed that in general people connect a lot on Facebook, how do you keep up with status of everyone? Why do you want to be friends with people you aren't really friends with? Why do relationships have to be mutual?

Why do people share links to Facebook that require a Facebook account to see? I hate when I see updates on Twitter that link to Facebook page and I get a login screen.

Seems a lot like the old AOL if you ask me (those were the days). A lot of services inside a single platform.

I don't get it, and it confuses me. Somehow, my mom uses Facebook from a Blackberry. I am a computer science graduate, developing software for the web is my day job. My mom just asked me where she could get a type writer, but somehow she can use Facebook on a Blackberry. If baffles me how she can understand the interaction on her phone, and I can't even understand it on a full screen browser window.

Must be me.

Monday, May 23, 2011

SimpleModal and ShareThis - Positioning and Ajax

I recently had to fix an issue with the implementation of a ShareThis button in a SimpleModal. Easy right? Sort of. Below I will walk through my issues and the fixes. The screen captures are intentionally blurred. This is a bug fix effort, the base implementation already existed, so I will not cover how to setup a basic ShareThis button or SimpleModal. Refer to their respective web sites.

ShareThis container position 

The first issue is that the SimpleModal remains positioned to the window and as you scroll, the modal re-centers in the middle of the browser window, the share this container doesn't. See the image below. The page has scrolled down, and the ShareThis is remaining placed and will eventually remove from the screen. The initial flyout of the ShareThis is mostly directly under the button placement. This is not the case here.

To solve the problem, the ShareThis container needs to be moved around when the page scrolls. The container however is an iframe, and the actual containers you inspect will be contained within that frame, and therefore you cannot act on those elements in Javascript. The ShareThis content is sand boxed from yours due to the cross domains.

The implementation fix will move the ShareThis on a page resize and to set ShareThis frame position as fixed. The ShareThis is offset from the SimpleModal:

var offsetFrom = $("#simplemodal-container:visible");

This will position the share this modal against the corner of the SimpleModal. I'll explain the visible and the z-index in a bit.

Multiple ShareThis buttons on Ajax page loads

The ShareThis buttons don't really work on Ajax calls that return HTML and Javascript, meaning the ShareThis button is defined in the synchronous data. The implementation I worked on was a search results page with a modal view per product. The search results has paging and filtering options that fire Ajax calls and returns the needed JSON to adjust the page.

By default, the ShareThis code will only execute once the initial DOM is ready, any additionally added items, will not be setup as share buttons. The ShareThis code provides a method call to relocate the buttons on the page for setup:


Execute this inside your Ajax success callback in order to setup the buttons on the page.

But before you can locate the buttons, they need to be added to the page. As I mentioned, the page load was Ajax returning JSON for the search. The page results are built client side and each result as a modal that is also fetched with Ajax, but returns HTML (where the ShareThis button needs to go). The HTML results can't include the ShareThis button due to the way the button elements are located. Therefore, the HTML result just has a place holder that is later replaced with the actual ShareThis button. See the following:

var shareParentPrependTo = $("#modal-share-this").parent();
// find the share this element and prepend it to the parent so it appears first
$("#share-this-" + id).prependTo(shareParentPrependTo);
$("#share-this-" + id).show();

The "#modal-share-this" is the placeholder. Then the actual ShareThis button is prepended to the placeholder's parent. There is a ShareThis button per search result, where each has a unique ID to use for selection. The actual buttons are hidden in the page until that result is selected. It's then added into the modal and shown. These unique elements are built via the JSON results, then added to the modal container.

Closing the ShareThis button - Positioning

When moving the ShareThis container, the clicking on the "X" to close the flyout on click did nothing. If the hover option was on, then the flyout would go away after moving the mouse away. But when this wasn't the case, there was no way to close the ShareThis container once opened.

At first, I was trying to inspect the close button but then realized that the inspected element was inside the cross browser frame, so I couldn't act on it even though I could inspect it via Firebug. I couldn't adjust the click event for example.

Then I noticed an element outside of the frame "div.stclose". For whatever reason, the element "div.stclose" was positioned elsewhere on the page and not over the closing corning of the ShareThis container. The result was having to reposition the "div.stclose" element with the overall ShareThis button as well. The trick is, rather than having the close button on the top left, the button needed to be the top right of the container (not too complex).

// frame width
var closeWidth = parseInt($("#stLframe:visible").css("width").replace("px",""));

// frame left corner
closeWidth = closeWidth + parseInt($("#stLframe:visible").css("left").replace("px",""));

// left corner minus the width of the close icon
closeWidth = closeWidth - 12;

$("div.stclose").css("left",closeWidth + "px");



As shown, the width of the ShareThis is added to the left corner to get the right corner. I am not sure if the "px" replace and additions are needed above, but they work. The position is then moved in 12 pixels which is the width of the button. The close is aligned with the top of the SimpleModal (offsetFrom). The position must also be fixed to ensure the page scrolling doesn't move the element out of view.

The z-index of the ShareThis container is important here. The "stclose" element must be index above the iframe contents so it can be clicked by the user correctly. If under, then nothing would happen.

Closing the ShareThis button - Remembering ShareThis elements

Now remember, the buttons are hidden in the outter page, and then moved to the modal when shown. When the modal is closed, we need to move the added ShareThis element back out into the window, incase its added again. Otherwise, we will have lost the ShareThis element for the given ID.

It doesn't matter where it goes back to because it's hidden and we can select it by ID later. Therefore, the onClose event on the modal needs to be adjusted:

$('#modal').modal({ onClose: function (dialog){
   var shareThisBackToWindow = $("#modal-share-this").siblings(":first")

}} );

The first sibling to the "#modal-share-this" element is the added element that was moved from outside the modal, then into it. This needs to be moved back somewhere else now, "#whatever", then hidden, and then the modal can be cleanly closed. If the modal was just closed, the ShareThis button would be destroyed for that ID.

This is why the visibility selectors are in use in the examples. Since many button elements exists, we only want the one shown to act on, verses the hidden. This applies for the ShareThis, verses the modal which is removed and then re-created.

Easy, right?

Took me about 3 days to break this down, understand the problems and fix it. I also had to fix the scroll bar shown in the screenshot inside the modal, but that was easy. I saw a lot of Ajax questions on the ShareThis forums too with no good solutions, except for the "locateElements" thread.

Hopefully this helps someone. If not, it's at least good note taking for myself.

Friday, May 20, 2011

Give me time to understand the problem

I am not sure what kind of technologist, or software developer, you are, but for me, I need some time to dive in usually when a problem arises and I need to explain why. Especially when a client is asking "what's going on?".

I don't know everything off the top of my head, especially production edge case problems that I never understood before. Or the crazy things your user's have done that I would never do. I've forgotten much more then I remember at this point in my life. I can't retain details in my brain. Software and technology is hard, really hard. It's harder than writing books. Websites are complex and the code that runs it full of bugs.

Sure, I can draw from past experiences and make something up, which is a guess, without looking at a single line of code, or a single log statement. But I'll also tell you that I am likely 80% wrong in my assumptions and so are you.

Ask a question, let's limit the back and forth to a few minutes. Give me some time to look at the issue, like 2 hours, then we can dive in and talk about a corrective path.

Oh yeah, open me a ticket as well so I can track time and information about the issue.

Tuesday, May 17, 2011

Looping... it's been driving me crazy

I've been told I am stupid and / or crazy, but looping concepts have been bothering me.

For each, iterators, next, while, whatever. All that spinning, all the indexing, all the positions, the head, the tail, push, pop, sorting, reversing, slicing, dimensions... So much one after another, so much sequence. I really don't like it. Whenever I see a loop I think "blocking", I think "waiting". I think about people in lines waiting to get to the front. I think about the length.

I've convinced there has got to be a better way, but I am not sure what it is yet. The associative array is a little better, but its still a collection that demands iteration. Hash tables are close, but I always find myself wanting the keys.

The array has been burned into the computer science mind since the beginning. We've been forced to think this way based on text books and forced given the current computer architecture.

So what if we remove the commonly known ways to act on a collection of elements? What would we replace them with? How would we think differently about acting on that collection?

Maybe events and listeners? When the collection is alive and an element meets a condition then the listener is executed. I like how jQuery selectors work agains the window as the container. Window contents can be a result of many selectors, but remains in the general window container. Then you can execute events on items in the window. The binding and the triggering is more of what I am suggesting in general element interaction. With this, you wouldn't really collect elements, you'd create them.

Maybe distributed accessor to adjust the collection? As cycles are available, act on the collection. Then I can at least work on more then one part of the collection at a time. The listeners mentioned above would be threaded in this mannor.

I want to remove the "element" concept and focus on the collection. What does the collection mean? What will I gain from something being collected?

Meditate on this, I will.

Monday, May 16, 2011

Integrations I really like for sharing

There are several integrations on the web I use regularly to save and share content, typically links to other sites I've read.

Feedburner Link Splicer

The Feedburner feed link splicer will integrate bookmarked links from another feed into your blog feed. I use this to add the Delicious bookmarks into my feed. It generates a daily link list that I've saved. For example, if you look at the following feed URL in the browser: http://feeds.feedburner.com/AWordOn.

You will see posts similar to "Links for 2011-05-13 [del.icio.us]". Reminds me of the O'Reily Radar's four short links posts.

Delicious to Twitter 

With Delicious you can add your Twitter account for bookmark sharing. I use delicious to save my bookmarks, I also use Twitter. I like to share links on Twitter more so than commenting. Within the posting process to Delicious, you can add "@twitter" into the "send" option. The post is then sent to twitter with the page title information and a shortened URL. This works in the browser plugins as well as on the site page as well.

Visit the sharing options in your Delicious account to check it out.  You can see my Twitter shared bookmarks as well for example.

Flickr to Twitter

The Flickr to Twitter is interesting to me mostly because of the inclusion of the mapping data of the photo to Twitter. You of course need to add the photo to the map.

For example, see the following post I made to Twitter recently of a photo I took downtown Cleveland:


Below the post data, the image is shown, which is normal, but then the map data is also shown.

Saturday, May 14, 2011

Acting out messaging without impacting others

I noticed something about myself recently. I often have a response to various threads in email or online. I keep these in my head mostly, think about what I might say and then don't. Sometimes however, it's hard to resist contributing, so I start to build out the response and type. Then about midway through I think to myself, "shut up", stop and delete.

I think this has something to do with acting out without impacting others with additional distraction or input. In most cases, the response is to an idea or problem. Naturally, people like to build on ideas and solve problems and so they speak up and contribute without holding back. I am the same, but as soon as there are too many people involved, I am turned off to speaking up.

I am also turned off to the thought that I consider myself simple and at an average intelligence level, so surely someone else will shortly chime in with the same thought. My input is obvious, so why bother? To my amazement, most of my input isn't shared in the same time, so I at least give an hour or two before someone chimes in, and then they do.

But I still have my point of view at the given moment,  what to do? What I end up doing is opening a reply and punch out the thought, read it to myself, and terribly I discard. Sometimes I will save it as a draft, and let it linger if I think the outcome might be worthy of being sent later. I also save as draft in case a later though arrives for inclusion.

It's really for my own benefit so I can move on and follow the next interesting thing. Somewhat like closure. I compare it to the physical, for example when aggression is acted out in the form of violence. Something is broken or harmed. That's the negative comparison, but there are positives as well. Regardless of the form, its a simple outlet.

Ironically this post was almost a direct example of the topic. This thread was in draft during the Blogger outage and was temporarily deleted before posting. I thought to revive the thread to post it from scratch, but I blew if off and accepted the closure. I decided, who cares and again told myself to "shut up". Since it was revived after my closure (see update in thread), I figured I needed to make mention of this in the post for the update prior to publishing. So please accept my apologies for not holding back.

Friday, May 13, 2011

Don't text me professionally

Major pet peeve of mine, texting professionally.

If we work together, you should not text me. If you are friends with me, or are my mom, you can text me. Otherwise, call me and leave a message.

My colleagues will argue they don't want to call me. If that is the case, then it's really not that important and it can wait. Sent me an email.

My colleagues will then argue that I don't have email on my phone. That's right, I have a candy bar phone, its a LG Glance if you care. I am on my computer about 10 hours a day during the week, 2 on the weekend if I am not working. I want to have a way to disconnect, and I do it this way. Don't like it? Tough.

My colleagues ask, when can we be friends when and then it's okay for texting to occur? My response is when you or I leave this company, we no longer work together, and by chance we happen to be friends.

This is my preference, in general I don't think texting is a proper form of communication for the workplace.  Email and instant messaging alone have contextual issues and cause misunderstanding. I do appreciate the demanded short structure of the message that SMS provides, similar to Twitter, but it just doesn't feel right to me. Call me old fashion, but I prefer an email, or a phone call. If I miss the call, leave a message.

Monday, May 9, 2011

How I estimate web work

At my first job out of college I was asked by my manager how long I thought something was going to take after discussing design and approach. My response at that time was laughter, literally, I had no idea. Nor did I accept this question as important in any way. Building takes time and it takes the amount of time it takes me to build it.

At my second job, I was initially victim to someone else's estimation of work. Usually senior developers on the team, or the project manager would estimate given there was nobody else to do it. If something went wrong, then I would just blame the estimate, or the fact that web work is sometimes unpredictable and crazy things happen to blow up the amount of time something works.

While still at my second job, after my first major site launch, I was enterend into a more structured estimation process. We were estimating the build in large chunks prior to even design. It was a high level estimate for the client pitch. We estimated in buckets of easy, medium or hard, which was usually 20, 40 and 60 hours respectively. The estimates were wildly broad and large, but it was a major extension effort of an existing site we just finished, so we had a good known rhythm of the development team and client. This effort ended up being very close to the base estimates, we were roughly a few weeks late which is nothing relatively speaking.

Still at my second job, I somewhat moved up into the position to be the primary technical resource to come up with estimates for an upcoming new project. I thought to myself, "oh shit". How do I estimate a whole project, start to finish? Where do I start? Luckily, someone else already went through this and tossed me over a spreadsheet they used. I took it and ran, changed it around and made it work for my project.

Now at my third job, per release, we are estimating work. This will be a common thread for all developers as you age and are taken more seriously. Managers and clients will always want some reasonable schedule they can plan on.

Break it down

Here is what I did and do. This might seem entirely obvious, but I've never seen it written down, shared, or taught for that matter. Maybe I haven't really looked either.
  • Break it down as far as you can
That's it... 

Break it down further

Well I guess that's a large task. So, let's break that down further. 
  • Break down components
Alright, that is manageable, what are the primary major site functions of your site? 
  • Search
  • Registered customer area
  • Public API
  • Caching
  • Sign up
  • Checkout
That's enough for now, I am sure each site has many or fewer areas. Let's use sign up as an example. 


Now let's break that down. What makes up the component of "sign up" on a web site?

A lot of what comes from breaking down the component is starting with the UI. What will the customer work with and experience? Starting from the other end (data) is a lot harder and I don't recommend it for web estimation. Maybe for data warehousing where all work is internal this makes sense (starting with data). On the web,  the interaction will drive the data, or at least the data that mostly matters. 

What makes up a sign up? Hmm....
  • Site header link
  • Sign up primary page 
  • Sign up form 
So we have a link in the header to sign up for an account. That directs to the primary page containing the sign up flow. That page contains a form. 

We've got some work now, we need to build the link and integrate the link into the existing information architecture of the page. We need the primary page developed. It likely fits into a template clamp and then contains unique content. The form will have elements such as user name, email, password and a submit button. The page will have styling, the form will have validation. 

Breadcrumb Model

Alright, let's organize this information. It's good to use a naming structure, kind of like breadcrumbs to organize the list within itself. This naming his helpful during search and sorting elements in a list or in a ticketing system and is why I like it. Let's breadcrumb:
  • Sign up - Header Link - Integration of page with existing header links
  • Sign up - Primary Page - Apply page styling and page element layout
  • Sign up - Primary Page - Form - Add form validation pre-submit 
  • Sign up - Primary Page - Form - Add form action  
Whoa, wait, the form action? What the hell am I going to do with this data? Well how about I implement some sort of controller to handle the data, transform it and store it. 
  • Sign up - Controller - Add sever side data element validation
  • Sign up - Controller - Add data storage logic
Gah!! The data, where does it go? I think we need a model. 
  • Sign up - Data - Develop user sign up model entity relationships
I think we are looking good now.... but what if something goes wrong. We need some error handling items as well. 
  • Sign up - Primary Page - Add error messaging highlights or modals for user
  • Sign up - Controller - Add server side error handling 
  • Sign up - Controller - Add user de-duplication 
What about integration? Usually data doesn't just sit on the web, it goes somewhere usually to a master or central location? Let' add some break down for third party integration synchronization of user accounts. 
  • Sign up - Third Party - Add third party controller
  • Sign up - Third Party - Implement real time data mapping to third party
What if the third party was down, having an outage?
  • Sign up - Third Party - Implement third party retry logic
Let's stop there, we can go on and on depending on requirements and scope, but let's keep it simple. 


Now, how long will it take? Given the vage details, let's gut check it by conceptualizing into easy, medium and hard. Then we can apply hour range as such:
  • Easy - 2 to 6
  • Medium - 6 to 10
  • Hard - 10 +
Overlap, yeah, it doesn't matter. There is a easy six and a medium six, trust me. Notice these times are different fromt he 20, 40 and 60 above. The range can apply to whatever you want, but in general for actual work that will be tasked out, keep it smaller.

What's with hard? Hard isn't capped because its hard. Sort of like my first experience of estimation at my first job. You might not know what's happening until you get in there and really figure it out. Maybe 16 is the cap, but beyond that, think about breaking down that complex task into generic parts. 

To apply time, lets organize our list and mark times. Along with times, you'll want to add an assumptions as well. You won't remember why you estimated a certain way unless you mark it. Let's just mark time for now:
  • Sign up - Header Link - Integration of page with existing header links - 2
  • Sign up - Primary Page - Apply page styling and page element layout - 8
  • Sign up - Primary Page - Form - Add form validation pre-submit - 6
  • Sign up - Primary Page - Form - Add form action - (wash per item below)
  • Sign up - Primary Page - Add error messaging highlights or modals for user - 2
  • Sign up - Controller - Add sever side data element validation - 6
  • Sign up - Controller - Add data storage logic - 4
  • Sign up - Controller - Add server side error handling - 2 
  • Sign up - Controller - Add user de-duplication  - 3
  • Sign up - Data - Develop user sign up model entity relationships - 8
  • Sign up - Third Party - Add third party controller - 2
  • Sign up - Third Party - Implement real time data mapping to third party - 3
  • Sign up - Third Party - Implement third party retry logic - 12
Let's explain some
  • Sign up - Primary Page - Apply page styling and page element layout - 8
    • Some thing front end work is easy. It's not. Layout, interaction, browsers, etc. This takes time, 8 might not even be enough. 
  • Sign up - Controller - Add data storage logic - 4
    • Only 4?
    • Yeah, the model development isn't in this task, find the record, insert or update it, done.
    • Be sure to clearly separate work so it's understood when which part is done
  • Sign up - Third Party - Implement third party retry logic - 12
    • Why so much? Might not be enough. 
    • We need a retry model, a schedule, etc. 
Organization column model

We've now conceptually finished the sign up. Now repeat. Organize this all in a big fat spreadsheet. Column model in the sheet is:
  • Component
  • Component Breadcrumb
  • Hours
  • Assumptions, reasoning, justification, whatever
If you want you can also add the following:
  • Phase - allows for scheduling in releases
  • Change - allows you to know if the item is a change per the client given original data
Possible component breakdown areas 

Each component section can be though in these areas as possible breakdown areas:
  • Page design, UI flows and site templates
  • Page to data integration
  • Controlling logic, or server processing
  • Data modeling 
  • Errors, exceptions, monitoring and logging
  • Performance
  • Caching
  • Security
  • Scheduling
  • Pure integration (might be a duplicate of server processing)
  • Go live, or release preparation
What about testing? Tests are a true aspect of all work, vereses security or performance, sometimes they just dont matter, but testing always does. Be sure to pad the time the developers will need to regression test their work. 

What about code reviews? Same as testing, pad the time the developers will need to get their work reviewed and incorporate changes. 


Next, load into ticketing system in batches per timing or major release, assign to developers, tell them to record actuals, then learn from what you missed and apply next time. I do not recommend loading all breakdown work into your ticketing system prior to the schedule time it can be done, use a few weeks as a cycle. Likely the work will change, and you will have a terrible amount of clean up to do on the ticketing system. 

Appendix: The work changes?

Oh yeah, version your sheet per major adjustment. Either naming, or literal version, you are going to need to be able to see the evolution of your break down estimation as you go. Similar to the loading issue, you might want to stop breaking down work until you are nearer to actually doing it because there is a likelihood it will change. 

Appendix: Don't over distribute work

Task breakdown and estimation might lead to the thought of "many developers progress more quickly to the goal line". Big mistake. Understand order, grouping and dependencies between tasks. Keep a person within a component, or two, not 8 people. You dont need 4 guys writing the sign up form. 

Appendix: Credits

I learn a lot from the people around me. I was helped a lot to gain this knowledge over some time and terrible experiences. I want to thank those people, but I won't mention them here. I will stick with my typical nameless and vague posts. If they demand credit, they can:
  1. Read this blog
  2. Ask for credit
Then I will gladly update the post. 

Thursday, May 5, 2011

My professional goals

Once again, I've been asked to write up my goals for my job. While I agree this is important, corporate guidelines around how I set my goals, the structure, and / or templates I don't agree with. I think it helps getting started, keeping an eye out on what you want to be, and setting a path to getting there. I have yet to actually execute on any goals professionally as my project work simply gets in the way of doing what I think is interesting. Makes it hard to be measured against something a company ask's you to set out prior to knowing your project work.

I also feel my goals are mine, verses the company's. I hear they are suppose to align, sure, but I can't align with all parts of a company's direction, if I did, it would be my company. Nor can I execute on a company's entire direction. I also don't care if they are SMART (Specific, Measurable, Attainable, Realistic, Timely).

That said, corporate goal setting should be simple and aligned on the individual to allow them to grow how they want to grow while helping their employer's bottom line, verses making the individual set goals based on what the employeer wants of them. If there is complete misalignment, either the employer or the employee made a wrong decision by partnering with the other.

Regardless, the following are my professional goals simplified beyond a company's structure and/or template.
  1. Read a lot of technical news articles, blogs, and generic content I find interesting and share it. Yes, I want to be measured and rewarded for this professionally. This will allow me to share items with those I work with that are interesting, and keep conversation of technical things beyond what I am actually doing. And if you are an employeer and you think your technical folks don't spend about 2 hours a day reading internet crap, you are wrong. 
  2. Contribute as much as I can internally and externally what I've learned based on my work done while an employee. This involves write ups and in-person presentations, doing demos and proof of concept type work (see #5), code reviews, approach discussions, etc. I want to talk and be known by my peer group. 
  3. Always be building and never just conceptually designing and/or architecting. I feel people who do just design and architect lose their edge. There is something about people who can build better than design that I respect so much more. How can I respect myself, or others respect me if I am not hands on making it happen.  
  4. Always be building in different ways and changing as I go. I never want to be the same person I was last year, solving the same problems and using the same stack. I want to move around and solve problems in different ways on different teams. Sometimes I think I know what I want, other times I am surprised by what I don't know. If there is a job, but nobody is a good fit, try me even if I have no background in the area. 
  5. Participate in in concept projects, research, idea generation efforts for no good reason except that technical people feel its important. Along with this, being involved in open source projects, or openly developing for the community on these projects or efforts. I never like hearing about "special" projects, it just means I wasn't the guy telling someone else about it. Always gave me the sense I was missing out on something special. 
  6. Specialized in performance and / or data aspects of a solution. These go hand in hand mostly, its more and more important to act on data in a timely fashion. If something is taking to long, and it needs to be shortened, I want in. If it involves a lot of data, I want in. I am just interested, I am not sure why. 
  7. To work on teams with members smarter than me. I never want to be the smartest guy in the room, I'd rather be learning than teaching. I'll do both, but if I were to pick one, it would be learning. 
  8. Be sent to conferences. 
I'll leave it at that. 

Bad technology doesn't mean you can't make money

I've had a couple corporate jobs. I've been in consulting for a bit now, so I've seen other companies software and technology. I've also been on the development teams writing the software for these companies.

If you haven't been on a development team for a company or seen the code that runs portions of the company that makes money, you'd be amazed how terrible something can be but still work and make money for that company.

What's harder for me to understand is if everyone knew the technical quality details of the software that ran a company, would they invest in that company? Or even make use of their services? Is technology enough to make you move away?

As a comparison, would you live in a house that was terribly constructed, or drive a car with bad engineering quality? Not likely. I wouldn't.

I use services of companies I know are not great, but they are good enough. The company product is likely more valuable than the pieces you and I interact with on the web anyway. The company direction and ability to make money and return on my investment is what matters. If the technology doesn't get in the way of that, then who really cares? Only technology people care. If the details were in the company reports, who would understand it other then us developers?

Normal people don't care about technology and software, how it works and what it does. They care about the impact it has in their life to make something better or easier. This is why companies with bad technology still can make money.

Sunday, May 1, 2011

When is it okay to customize a library?

I was working on an issue the other day and I noticed some Javascript libraries being used had been customized. Meaning the person who changed the library was not the author and/or is not a contributor on the originating project. Immediately it felt dirty. When is this okay?

In the particular instance I was working on, the Javascript library was a jQuery history module for remembering and refreshing page state given Ajax calls. Simple stuff, but the plugin was old, not in active development, and frankly didn't work (I might write this up later). The link in the comments for the project page didn't even exist.

So what do you do in this senario when dependent site functionality is not working correctly? Do you (1) patch the plugin or customize it, or (2) replace it?

The right answer is (2). The plugin is out of date is isn't working correctly, it needs to be removed and all dependent code updated to use something that does work.

I did (1) due to timing. I put in fixes into the plugin, added some clean up code to fix the issues. The fixes were very narrow to the problem scope. However, I still felt dirty.

I realized, in general, I don't ever want to do this. Sure, sometimes you might to just need to get the job done, I've been there. However, the "module" should be self contained and untouched. The module should be used, not embedded in your solution. You need to be able to update it and remove it if needed. If there is truly an issue in the plugin, open a bug on the project page, submit a patch and get the next release. Otherwise, fix the problem outside the module.

I also realized version management in Javascript modules isn't so easy within another project. Especially when you download the sources locally. If it works, why update it? Well actually, there is a reason that software is "released" over and over again. It has fixes and enhancements to make it better. Therefore, usage of that module will get better as well, verses just working. Same reason you make updates in your own projects.

These are general problems in Java as well (and everywhere else). We download source JARs, add them to our projects, and then we customize it. Those base JARs are also released with updates, but the base remains.

I then thought, how is this prevented, why don't people update libraries in their projects? Because it's talked about before hand and the "risk" factor is involved. Talking about this out load with senior folks on a project, or with your project manager, and worry will soon come. It's nobody's decision but technical folk to change something like this. Don't involve people who should just be users in the discussion. You will get talked out of bettering your changes, or simply overruled because the impact will seem high and too risky, verses doing the right thing for the long term.

To summarize, don't customize your libraries being used in your projects. Update them regularly or replace them when needed. Seems like simple advice, but I haven't seen it done well in any projects I've worked on.

Share on Twitter