Stackoverflow.com Overflow

You know you’ve done it before.

  • You encounter an issue during your development cycle… no, no, better… during the second half of an uneventful Friday on the cusp of a bright and sunny weekend bursting with promises of R&R.
  • So you want a fix… FAST!
  • You google with the tightest permutation of error keywords.
  • A stackoverflow.com post tops the list of search hits. SURPRISE!
  • You click it.
  • Problem solved.
  • …or so you think!?

It doesn’t take very long for the bandage to come undone and expose the nasty gash you had thought you healed. Let’s stay away from specific examples because we all have our own favorites, don’t we? quote1

Before I go on, let me clarify that I have nothing negative to say about stackoverflow.com itself. It is a great aid to developers all around, as are other forums like it.

But there is something to say about the excessive reliance some of us in the development community exercise on this techie forum. We scan madly for the first post sporting that green check greencheck with little to no regard for the accuracy/relevance of the solution to our specific problem at hand.

I’ve been guilty of this too. It wasn’t until a covey of super-smart developers mocked me for one such hastily adopted solution that I did some serious introspection. Since then, I’ve been a lot more cautious and deliberate about how I use that forum (and any other) to my advantage.

So, here is a stackoverflow.com sanity checklist:

1. Start with some independent thinking

I’ve stressed this in a previous post too. Your first order of business when you have a problem is to think about it. You need to research the problem first before you research the solution. You can’t truly solve a thing you don’t understand.

So, step away from the desk and think about it for a while. You will be amazed at the dividends this little step pays. The subconscious is an amazing little beast that proffers ideas when you least expect them. But YOU have to take the first step of thinking about the problem, of prodding your subconscious into action first. Stimulate those impulses.

2. Spend some time on the post(s)

Read the problem description fully. Take the time you need.

Read the solution you plan to adopt fully. Take the time you need.

And finally (this is important), read every single reply to that post fully. Take the time you need.

Nothing feels more like a kick in the rear than discovering later that a solution marked as correct was soon after refuted by a community member with a note that is super-relevant to your specific scenario. Tragically the refuting response is right under the green check from heaven, but too obscure for you to notice because you are desperate for some of that greenness.

Read carefully. Take the time you need.

3. Test the hell out of the solution you adopt

Test. Test. Test. Test. Test. Test. Test.

Oh, and one more thing… you guessed it… TEST.

4. Get a peer-review

There is no substitute for a peer-review. In my experience, the best catches haven’t come from unit tests, or even QA cycles. They’ve come from casual reviews by fellow-developers eyeballing your code as they devour that last praline. (We had pralines in the office today.)

Besides, a peer-review is great at many levels. Even if the specific fix you adopted from stackoverflow.com is perfectly acceptable, a peer-review might expose an issue with the way that code is integrated into your codebase, or better yet, it might catch something totally unrelated to your fix, but critical to the greater good.

Your code is a shared cache of intellectual property. Get some eyes on it.

5. Record the source of your solution

Dedicate a portion of your commit log to referencing where you got the solution from. Personally, I like the version control commit log for this type of thing. Other places to record this maybe the wiki or even the issue tracking tool. I don’t think it makes sense to add this information in code comments, especially if the code is being delivered to another team or group, but if that fits in better with your development culture, that is fine.

The point is to leave some breadcrumbs for the next guy that stumbles across your adopted solution. If he or she is motivated to improve it, they will thank you immensely for the tie-back to where it all began.

Advertisements

Running a portal instance now

My new experimental portal is running at portal.temperateprogrammer.com.

portal-tp

I should have done this a long time ago. I’m using it to run the live code I blog about on either liferay.com or here. I also moved the code out into this Github repository.

This hopefully ties together a little bit nicer.

That was it. Oh, and my most recent installment is now on my liferay.com blog. Excerpt below.

Let me begin by clarifying that this post has nothing to do with the Harry Potter universe.
But seriously. You know what I mean by wizards, don’t you? Those helpful series of screens that gather a set of choices from the user and then use the captured choices to do something for the user. Often times, one user selection can lead to a different outcome that the other choices on the same screen.
It turns out I am faced with a requirement to build such a wizard. And the requirements are a little bit amorphous. So I asked myself the same question I have come to ask before embarking on a multi-layered application development effort:
Can I do accomplish this with the content management system?
Or more verbosely stated as:
Are all the layers I need to accomplish this already there for me?
Well, the answer is yes. It can be done using the CMS. And it can be powerful and flexible.

And… IT’S OUT!

I recently had the distinct privilege of co-authoring my first book with the incredibly talented Siddique Hameed who invited me  to join him on this writing project earlier this year.

1725_5068_mastering-android-wear-application-development

The book was released yesterday and will be available in ebook and print formats. It should be making its way to Amazon and other online stores in the days to come.

It was an absolute pleasure working with the stellar editorial team at PACKT without whom the book would not be in the final state it is in. To them and to everyone who had anything to do with this publication: Thank You!

Stopping By Abou Shousha’s On A Snowy Evening

I decided to try out something I have not done before, but have seen done pretty well: technical documentation through story-telling. I’ve always believed that knowledge-sharing can be a lot more engaging on the back of a story. So, here you go.
“I LOVE tags,” Jaffer managed despite a mouthful of spiced lamb ouzie.
Sergei was finding the younger guest a bit annoying. The kid had ambled in from the snow to get a bite. Sergei himself had come in to escape the noise that seasoned other cafeterias. He fancied Abou Shousha’s Mediterranean Oasis for its laid back ambience, not to mention the unending supply of Maghrebi mint tea.
And now, this kid.
“They’re okay,” he mumbled before returning to crafting an XPATH expression for his ADT.
Jaffer’s jaw dropped open.
“Okay? You got to be kidding me. Tags are PHENOMENAL. I mean, what else do you need to organize and query all that content?”
Sergei ignored him, but it wasn’t easy.
“Huh? Right? Am I right?” Jaffer persisted as shreds of ouzie drizzled out of his mouth onto the platter below.
Sergei broke away from his laptop and turned to face the young programmer.
“Have you heard of categories?”

Read more

I’m curious to see how the readership responds to it. Who know, maybe Sergei and Jaffer can become fixtures on these posts.

Braving That Interview

It never fails. Techie job seekers often equate preparing for an interview with immersing themselves in technologies and frameworks they’ve never used.

DON’T DO IT!

I’ve been there too, and it can be a fairly unpleasant aspect of what ought to be an otherwise pleasant search for a suitable next engagement. Remember: you’re a programmer… a coder… a developer… a software engineer… but most importantly, a human being.

Or as my kids might put it, a HUMAN BEAN.

Whatever label you choose to tag yourself with, the one attribute you share with the broader species is potential. That’s right: POTENTIAL.

That means you don’t have to know everything. You can’t. All you need to convince your interviewer of is that you can solve any problem in reasonable time, and if possible, in progressively lesser time as you go about it. And there’s no better way to make that case than to be yourself, preferably the best version of yourself.

YOU are the valuable asset they will be hiring, not the current snapshot of your knowledge. In fact, you don’t want to get a job at a place that only needs your knowledge. Such a shop wouldn’t care about retaining you. They just need what you know – the commodity that is your knowledge. And if/when their needs change, you’re dispensable to them. They should be dispensable to you.

Here’s a laundry list of what I believe you should and should not do when you prepare for your next interview with any firm out there.

KNOW the basics

You should be VERY familiar with the basics of your core development platform. If you’re looking to be hired as a Java developer, you’d better have a decent understanding of classpath and Hashmap and exception handling and the ubiquitous String class and a plethora of other foundational concepts. If you don’t, this might be a good time to strengthen that foundation rather than pick the next framework named after some arbitrary workman’s tool or vegetable or yard pest.

Interviewers worth their salt will want to hire someone who knows how to peel the layers off of a complex application and work with the raw concepts, and if needed, dive down to the wire. That someone is a human resource who can change direction at any time no matter what framework or tool is thrown at them. Knowing the basics makes you flexible and adaptable in ways only your employer can appreciate.

KNOW well what you claim to know

You SHOULD NOT be studying frameworks you’ve never used. You should rather spend your free time solidifying your understanding of the frameworks you HAVE used, and ONLY to the level you’ve used them. If it’s on your resume or on your tongue during the interview, you better know it well.

DON’T be afraid to say: I DON’T KNOW

Technical interviewers hate BS. They LOVE a quick IDK. And here’s the big kicker: Say I DON’T KNOW anytime you don’t know the answer, and as much as you need to. The chances are you will eventually be asked if there is anything you do know. That will let you drive the interview and focus on the things you are good at, technical and otherwise. An interview is a conversation, and sometimes an interviewer needs to be pulled back. Don’t be afraid to be the one pulling back.
And if you don’t get the job because you couldn’t answer any of the questions, you’ve accumulated valuable knowledge for your next interview. You’ve also saved yourself from a potentially bad match. Always think win-win, because it is.

KNOW yourself, know your master

Okay, nothing sufi here. I suppose all I’m saying is: do your homework. If the job requires skills you don’t have, or if you don’t really want to be doing any of the stuff advertised in the job description, don’t apply to begin with.

If you’re working with a recruiter, let him/her know how you feel. You’ll be surprised how much they appreciate that sort of information. In fact, it sharpens their saw as they hack through the forest of opportunities out there to find the job(s) that might be a good fit for you.

Alright, enough with the cheesy KNOW  aphorisms.

Get excited about problem-solving

Beware the scourge of what I’ve come to call Stackoverflow programming. I’ve been victim to it too at some time or another, and I fondly remember my peers who mocked me on account of it. If you’re always reaching out to find a solution on the internet, chances are you’ve grown a bit rusty at precious old-fashioned problem-solving.

Lose the habit. Your first response to solving a problem should be independent thinking. Stackoverflow will be there for you if you need it once you run out of ideas. This is critical for you on your current job before you start looking for your next job. I can’t stress it enough: Get excited about problem-solving.

Don’t be afraid to code

Get used to being thrown a code snippet and being asked to fix it. That’s what you’re getting hired to do. So be ready for it. Expect it. Get ready if you’re not there yet.

Get into the habit of thinking in English

This can be a challenge for non-English speaking programmers who often think symbolically in their own vernacular. This is nothing to be ashamed of. At an interview, you will most likely need to articulate your solution as you think it through. Often times, the questions you’re asked at interviews may not have an answer, let alone a correct one. Some questions are asked to see how you demonstrate your analytical skill in understanding a problem and devising a solution for it.


That’s all that comes to mind right now. Hope this helps someone. I have a couple friends looking for jobs, and that got me thinking about what I consider to be an ideal candidate.

I’ll sign off with this. The ideal candidate MUST BE BRAVE while interviewing. That is the sort of courage that comes from being honest to ourselves, from knowing what we know and what we don’t, and being okay with it all.

Content SEO Title – Putty In Your Hand

 

In my last technical post titled Content SEO – Hidden in Plain Sight, I exposed a caveat in the way the title of a content item is auto-crafted by Liferay. Here’s an excerpt from that article, which I hope highlights the problem. If not, I encourage you to give that post a read..

Note that the Title specified is Young Night. But if you look at what got into the page source above, you can see we had: Young Night – Browse Poems – Liferay. The page name and site name seem to get suffixed to the Title.

So, here is how I solved it:
Lunch!

Over at LSNA2016, I hunted down the Content Management Roadmap table and found Julio Camarero crowded by rabid developers bombarding him with all sorts of CMS questions. I took my seat across from him… and waited.
…and waited
…and waited
…AND WAITED!

I eventually spied the door open and shamelessly stuck my foot in. In a blast of what felt like 400 words, I explained the problem as alluded to in my previous post hyperlinked at the top of this article.

Julio nodded and responded with – I paraphrase – “Yeah, there’s a JSP in the asset publisher where we construct the content title in that way. Email me in a couple days.”

Here’s the full article on liferay.com.