Wednesday, April 16, 2014

Java EE is mature. You can write a full enterprise application by purely using Java EE API's.

I remember the day when Spring framework was the dominant framework in the Java EE world (and many started saying goodbye to their little frameworks such as Apache Struts 1.x). Granted, it introduced features that is now integrated in Java EE framework (i.e., dependency injection) but I was too hesitant to jump onto the bandwagon for various reasons:

  • "Many" was jumping onto the Spring framework. My sole answer to this was that one day Java EE framework will be matured and there is no need to download MBs of jars to make a simple application.
  • Certification, certification, certification: Don't you just hate it when a new product is out on the market and you need to get yourself certified to be known as an expert of that product? There are various frameworks out there that can do the same functionality as the other, so it's a matter of taste and preference. (You may ask, am I Java certified? Not yet!).
  • Jack of all trade: I am always told that Spring does "everything". Generally, I have yet to see an application that uses every feature of Spring.
I am not shooting down Spring framework, in fact I have used it myself and I use it due to its simplicity in getting written code to run (i.e, you see productive results in quicker time than when using Java EE API's). This can be greatly attributed to Spring template helper classes and very (if not no) configuration required. The problem I had was that my simple web app was over 13MBs bundled WAR file because of various Spring dependencies jars. Also, I was one of the rebellious people who said that Java EE will mature and when it'll mature, I will be amongst the first to embrace it and move on. Now, I can tell you that my current web application (which has no dependencies on any Apache modules, Spring modules, etc. and just pure Java EE API's) is less than 6MB's WAR file. The other are web frameworks bundled such as Twitter Bootstrap 3.x, Font-Awesome, WooThemes FlexSlider, etc. (it'll soon be replaced by it's CDN URL, so the size of the WAR file will drop).

To understand what I mean, see the Fifty Features of Java EE 7 in 50 minutes.


Will Spring framework die? I am not sure, in fact, they've aligned their framework to work with Java EE API's. Red Hat had a framework called Seam Framework and they halted its development on Seam3. I used it as well, and I liked it. The Seam team decided to take on a different approach and "merge" themselves with other CDI developers out there to form Apache Deltaspike. And no, it seems Seam won't die.

Back to Java EE maturity, by running your enterprise application on a Java EE 7 compliant container, you certainly won't be worrying of dependencies. Configurations are there, in some cases (e.g., setting up Resources such as Mail Session, JDBC Datasources, etc.) but I have seen that it's very minimal.

Yes, Java EE is now mature to compete with the likes of Spring framework & I believe that we can write a full enterprise application by simply using Java EE API's. In fact, I have already started.

What are your thoughts? Let me know in the comment below.

Adieux!

Monday, April 14, 2014

Software programmer or Software developer, what's the difference? (An open letter...)

Dear recruiting agents & H.R. recruiters.

Seeing that there are many open letters out there, I thought it's suitable to write this open letter. I hope, and believe that by the end of this letter one would have an insight in understanding what your mistakes are and how to move forward resolving it.

It has come to my attention, after numerous phone calls, job interviews and job descriptions, etc., that there is a confusion that has circumvent the I.T. industry. This confusion is the lack of identifying the difference between software developers and programmers and I believe that someone who is a software developer and a software programmer can shed light into the difference.

Every software developer started as a software programmer but not all software programmers are software developers. If you understand this clearly you will know exactly who to hire and fire (depending on your discretion, of course).

A software programmer is a person who understand a computer language and use the computer language to construct an algorithm and program flows for a specified task. This definition is still valid today. Though we have IDE's with good functionality and API's that makes coding much easier, programmers know how to complete the task by integrating API's together.

A software developer, on the other hand, evolve outside of the software programmers paradigm. They are developed to create a software product based on a client requirement. They are involved in the who software lifecycle: from user requirement, creating a project plan, designing the functional and non-functional requirement, provide implementation, testing & deployment/release.

For example, a software programmer will be give a task such as creating a functionality to send an email while a software developer might look at which module will require the email functionality and create one. Other module might be the web module, mobile application and cron services that are timed to send newsletter to clients at a specified time. In essence, a software programmer is an expert into an assigned domain, a software developer have solid understanding across various domains as they must be able to assemble programs to perform various tasks solve a larger problem.

In a nutshell, if you are looking to hire someone who will need to do daily application maintenance and support, hire a programmer. If you need someone to create a solution based on various problem domain, hire a software developer.

Hopefully, once you grasped this definition, you can hopefully grasped the difference between software programmer, software developer, software engineer and software architect.

Good luck!


Kind Regards,


Buhake "The Elite Gentleman" Sindi

PS: I found this blog after publishing this, hopefully they will be clearer.

Sunday, April 13, 2014

DAO's as EJB's. You are doing it wrong...

You will realise that there are tutorials on the web that shows, by example, the implementation of DAO's using the modern JEE (please, it's no more J2EE) technologies (annotations and CDI). What I find strange, however, is that many of these DAO examples/tutorials are designed to be EJB's as well (particularly Stateless Session Beans). Even Apache, themselves, have a documentation that clearly makes a DAO as an EJB on their TomEE site.

This form of adaptation has crept, also, in business production applications that runs today (shocking, I know and it is still a practice done today by senior developers and architects). There is no separation between the (business) logic tier and the data tier (if you are creating a system using a multi-tier architecture). From my experience, developers do understand how to create DAO's and EJB's from examples that exists on the web, copy-paste the idea from the example and adapt it to their application requirement. As I said on my older post, many do not understand what the EJB container is, what it does and how it manages session beans (do you blame them?)

If you are creating a multi-tier system, you will realize that each tier is maintained as an independent module. This means each module is not dependent on other modules. The advantage of this is that each module can be created and/or deployed on/for different platforms and if each module is designed by contract, communication between each platform can occur between interfaces.

These are my reasons to why I discourage DAO's as EJB's: 
  • EJB's were designed to encapsulate business logic, DAO's were designed to encapsulate data to its persistence layer. I have read arguments that EntityManager is DAO pattern itself. Granted, DAO has been designed to form an ORM approach, the only different between DAO and EntityManager is that EntityManager exposes mechanism to make calls to the persistence layer, (e.g., a Getting a SQL Connection from EntityManager or creating native query by calling EntityManager.createNativeQuery(String sqlQuery);). DAO was designed to encapsulate this mechanism. The EJB should never know where the data is stored and how it is managed, as long as it can request manipulate and pass the data to the DAO to be stored, it's happy.
  • High coupling: The business logic and data persistence are so dependent on one another that a change on the business logic might/will affect the way data is persisted and vice-versa. High coupling classes/modules are bad classes/modules as an independent change to a class/module is not possible without affecting the other dependent classes/modules.
There are various more reasons but I believe you are smart enough to figure it out (please leave your comment below and state whether you agree and disagree to my statement). 

If I (strongly?) disagree on blending DAO's as EJB's, what is my recommended approach? Simple, create a data tier (such as DAO's) and Inject it, thanks to CDI (Contexts and Dependency Injection).

Injecting DAO's

Injecting DAO's is an alternative approach of requesting entity DAO's. For one, you can eliminate DAOFactory completely. 

Here are the steps to achieve DAO injection: 
  • First create a generic DAO interface and relevant subclasses that is tied to a persistence strategy (e.g. JDBCDAO for JDBC DAO, HibernateDAO for using Hibernate Session strategy, JPADAO for using EntityManager as persistence strategy).
  • For each entity, create a DAO entity interface that will provide methods that only return the entity requested. E.g., a CustomerDAO will only return a Customer entity.
  • You can used the @Named qualifier to specify the implementation of the DAO and finally injecting by the named qualifier.
  • An alternative approach that I took is to create 3 types of qualifiers: @HibernateDAO (used for DAO's that uses Hibernate Session), @JPADAO (for JPA persistence) and @JDBCDAO (for JDBC Connection).
It's easy to write a blog, but it's better showing an example (which works):

The DAO interface:


The DAO Implementation:


Note: The class is annotated with @JPADAO. This is the qualifier annotation that we specify for interface injection.

To create a custom CDI qualifier, create a custom annotation and annotate it with @Qualifier. Alternatively, if you're using Eclipse IDE (Eclipse Kepler and newer), you select the option to create a custom qualifier.

Here is the custom @JPADAO (see that it has the @Qualifier annotation, making it a CDI qualifier).



The BaseJPADAO is the DAO class that returns the EntityManager, contained from the persistence unit.


Finally, inject!!!


On my CustomerServiceEJB, I inject the DAO by interface and specifying which type of DAO I want.

And it's this simple. This runs wonderfully on my environment (Java EE 7 with Widfly 8.x). The EJB has no clue of the persistence mechanism of how the entities are stored, nor does it need to care. Since this was coded using a design by contract approach, changes to my DAO's won't affect the EJB at all, unless the interface changes and breaks the contract.

I hope this helps those who are designing a system with a multi-tier architecture.

Friday, November 22, 2013

Why should every developer (or technical experts) should become an entrepreneur?

Dear readers (and loyal fans),

Thank you for coming back to my blog. My sincere apologies for having deserted you for too long without any article to read. Hopefully, in the upcoming months, I can tell and show you the actual reason for my blogging absenteeism.

For months, I have been emphasizing my peers and friends that in one's lifetime, one should should become an enterpreneur. I have tried to best write my reasons on this blog but I was lacking words to best put it online. This week I, incidentally, started reading the book Start Small: A Developer's Guide to Launch a Startup by Rob Walling and the following segment from his book summarized it best for my case.





Why People Make the Switch from Developer to Entrepreneur

As a developer, your income, your ability to control what projects you work on, and your ability to control what you learn, end at a certain point.
For the first several years you’re constantly learning, working on (seemingly) fun projects and your income grows quickly if you apply yourself.
But the experiences of many veteran developers show that after a certain level of experience you can't push past that financial barrier. And keeping up with the latest and greatest technology – something that used to excite you – will begin to wear you down.
It’s hard to break out of that position and most often it requires a big risk. In my experience this risk involves joining an existing startup or starting one of your own.
I’ve tried both. I did it more for the excitement and freedom than for the income. In fact, I took a pay cut when I moved from consulting to owning my own products. But my passion for building something I own and the opportunity to experience true time and location independence far outweighed the drop in income.

Lack of Learning 
Part of your “topping out” will likely be a lack of learning. While it's true there are always new technologies to learn, as you mature in your technology career it’s likely you will begin to feel like a hamster on a wheel as you learn one more way to pull data out of a database. The idea of spending the time to learn how to do it using the latest method begins to make you tired.
It starts to feel as if you are constantly moving from one technology to the next which involves little “real” learning and a lot of learning some new syntax or API…things that will change in six months anyway. You start to feel like learning new techniques for the rest of your life will basically rehash the same things you learned in your first two years as a programmer.

Ownership 
I like to use the analogy of renting vs. buying a home. When you rent you have less commitment, you can move often, and renting is typically less expensive than buying. But you don't own anything and you don't build equity. When you move out you're not any better off than when you moved in.
Such it is with salaried employment and consulting. When the day is done you own nothing. Not only does this translate into a lack of financial gain, it's a mental challenge as well. Many find it hard to build application after application and never feel passionate about the application they’re building.
Once you launch a product, you are instantly building equity. With every copy you sell and every improvement you make, you are building something that will not only generate income in the future, but actually has value on the open market. Instead of having nothing at the end of your lease, you wind up getting back all of your rent money and more in equity.

I have yet to finish the book, and I have to say that it's one of the very few books that I have read on my spare time. It's a fabulous read with a simple English writing style that makes it a fantastic read.

I couldn't think of other reasons other than what Rob Walling just stated. It nailed it on the dot as I believe that we, as developers, end up to the forked road plenty of times in our careers. Technology will always be there, it's time that we drive to other, less travelled road and for me, it's best building a brand. A product that will have value.

So far, I do recommend to read the book, it has valuable insights that I, admittedly, never thought of. I still believe that the points provided can apply to anyone on the technical field. 


Let me know what you think, if you have read it.

Adieux! :-)

Monday, March 11, 2013

Are you a Human Resource or a Personal Brand?

Sculptors, architects, artists, entertainers, actors, designers, etc., already do this: Each of them have become a brand, a personal brand. They endorse their product/services with their name.

What about them makes them different from the rest of the population? They are not a (human) resource, but a personal brand.


What is a (human) resource?


A (human) resource is a person (preferably human) whose knowledge and expertise can be extracted to the benefit/satisfaction of the resource owner. To get the best out of the resource, the resource owner will "feed" the resource by providing tools, facilities, etc., necessary for the function of the resource in order to get what the resource owner expects and more.

Based on the statement mentioned above, one can see that slavery hasn't changed much over the years. Instead, you get paid for your knowledge/skills.

In order for the human resource to remain relevant, he/she has to remain knowledgeable to the skillset demanded by the resource owner and the market. If you've been hired to be a carpenter and if new tools/means are available to be a better carpenter, it's up to the resource to find a way to expand/grow with the new tools available. After all, the resource owner expects 200% from the resource, else a new resource will be required and the old resource becomes "garbage" (if you're a developer, you totally understand what I mean).


What is a (personal) brand?


Personal branding was introduced by Napoleon Hill in his 1937 book "Think and Grow Rich".

A personal branded person is a person who is marketed as a brand. This person is a unique self-package (containing identity, services, products, etc.) that is identifiable and marketable. Think of any of your favourite music artist/actor. Why do you follow them or buy their CD or DVD? That's because you know their brand and you identify to that brand that whenever their brand are on market, it attracts your attention.

A brand is an asset, etc., which has a unique identity that contains a established history/portfolio, which the stakeholders identifies to, and has a goal to benefit the brand and their stakeholders. A stakeholder is someone who identifies to your brand and is involved to the brand. E.g., there are many soft drinks products in the world, but many identify to Coca-Cola than Pepsi. The buyer of Coca-Cola are stakeholders to the Coca-Cola company.

An advantage to a brand is that it has history/portoflio. This is crucial as your stakeholders can see the thinking process that undergoes in a brand. This thinking process is not easily identifiable from a human resource, hence why when hiring a resource there are interview process to identify how the "resource" thinks.

Also, an advantage to a brand is that the stakeholders looks for the brand, not the brand looking for the stakeholders. This means that you don't chase money, money chases you. A human resource, on the other hand, needs to find an owner that will hopefully use his /her resource.

Don't be fooled, once you become a brand, it's all hard work from now on since you have to remain relevant as your competitors can eat out of their shares. Hence why a brand has vision. A vision to keep relevant now, tomorrow and hopefully, forever.

Advantages of being a personal brand?


Being a personal brand has its many advantages compared to being a resource:
  1. Your reputation precedes you. When your stakeholders sees your name, they see your history, they understand your work ethics, process, creative genius and knows what to expect from you.
  2. You know your nett worth. That is a plus since you can negotiate higher and not lower. A resourceful person cannot quantify as "accurate" their worth.
  3. There is a sense of individuality and uniqueness in the mind of others. Unlike a human resource who markets themselves through CV (and hoping they can identify a unique proposition that brings value to the employer), a branded person continuously creates awareness of their product/services to their stakeholders such that they don't see just uniqueness in your product and services but uniqueness through the brand itself.
  4. You are constantly creating a road-map to success. Don't get me wrong, everyone in their lives have a goal. The problem, however, is that human resource don't put focus too much in their goals as the personal brand. A brand is always aware of competition and, for survival, they always have to be an expert in their field or they "die" down.
  5. You leave a lasting impression. A stakeholder follows their brand in every sense of the word. With today's social media, it's even simpler to follow. When your stakeholders have positive lasting impression of you, it builds credibility, respect, admiration in such a way that it becomes a referrals to other stakeholders.

How does one become a brand?


Before the realization of the internet, in order to be resourceful, one had to invest their time, money and effort in getting qualified in a particular sector and, every few years, upgrade themselves in order to stay relevant. That's what every human resource does if they still want to be relevant to the business. This is measured through a Performance Appraisal.

It's now simpler in modern days technological world. You don't have to hire a branding agent to market yourself. Start small. What some do today is to create a blog and create an identity in their blog. Be involved in community projects, whether it be online projects or community-based projects. The main idea is to create relevance and reputation about you, who you are and what identifies you as a product and service for others to be able to follow you as a brand.

I hope I have got my case across. The more you work to become a brand, the more you will realize your strength and value proposition you can provide (as yourself) as a product/service and, finally, know your nett worth.

Thanks for reading this post.

Wednesday, February 27, 2013

Skanky exception, a dirty exception handler.

There was an interesting question posted on StackOverflow (asked on 27 February 2010) about programming Jargons (New Programming Jargon you've coined). The question was, subsequently deleted due to not being a question. Jeff Atwood blogged the top 30 answers from the deleted post here but if you have reputable score on Stack Overflow can view the deleted question here

The interesting jargon that I fully agree with is the Pokemon Exception



Pokemon exception is when you surround your statements with try-catch and  catch all exceptions. In Java, all exceptions are caught by catching java.lang.Exception.

This, pokemon, exception can transform to a new exception I call Skanky Exception (not coined by me, but from a work colleague). A skanky exception is an exception, thrown from the catch block, that contains has no reference of the actual caught exception. Let me elaborate via code example:




The skanky exception is on line 8. This is a dirty way of throwing an exception as doesn't encapsulate the thrown exception as a cause. Instead, it requires the developer to create a test environment, identical to live evironment, and recreate the problem step-by-step. If this is a severity 1 (critical priority issue), imagine the stress levels and coffee uptime the developers undergoes to find the actual root cause of the problem.
This was coined of the phrase we tend to say, "she swallows and likes to give bad head. A dirty exception.".

I was, initially, going to post this on StackOverflow but since the question/post was deleted, I decided to blog this instead.

What are the other jargons you've coined or did you come across, that hasn't been listed on links I've provided? Let me know by commenting below.

Thanks for reading this post. 

 If you haven't noticed, I posted this post exactly 3 years after the original question asked on StackOverflow.

Sunday, January 20, 2013

The future of software developers.

Happy New Year to everyone. May this year be a year full of challenges, hard-work and success in every goal you've subscribed to accomplish.

As a software developer, I have to always try to keep up-to-date as the software industry is growing at an alarming, and (doubly) exponential rate. This is the reason I'm always on StackOverflow: the question asked by other developers worldwide shows how software are evolving. If a developer misses the train of evolution, they will get frozen in the ice-age period of "This is how we used to..." mindset.

Now that I got the pleasantries out the way, I've decided to write this post on an observation seen from the many years spent as a software developer.

Being an "old school" developer, I have programmed with legendary API's, from WinAPI (Windows API) in Delphi, C and C++, to JDBC API in Java. Each language I've used, in my years of as a developer, shipped with API bundled in the Software Development Kit (aka. SDK). These API's gave developers the freedom to develop absolutely ANYTHING, based on their requirement/imagination. There was virtually no dependencies as the API existed in the SDK.
















Times have changed. API's exists in a new model called Frameworks. This, unfortunately, results in fast-brewing a new generation of developers that I call the "component assemblers/integrators". They are very fluent in downloading frameworks, libraries, software modules and integrates them together to form an application that they can deliver to business. If there are issues during the assembling (and in assembling, I mean assemble through code) and/or integration, they are quick to Google for solution/answers or ask question through StackOverflow. You can recognise them well, they post a question with a full exception stacktrace from 3rd degree exceptions.

My thought on the new generation programmers.

Today's developers have what we didn't have back in the day: A wide variety of platform independent programming language, too many (open source) frameworks to choose from and web services that are easily found through some UDDI registry or an easy Google search. 

There are advantages and disadvantages to these programmers:

Advantages:
  • They are mostly the creative bunch. Today's frameworks/libraries/applications, etc. are designed to make development time faster and simpler. This allows that development time are spent  building applications and also have fun doing it. This fast learning curve gives rise to creativity in broadening the horizon and bringing new features and new technologies rises. So, the vicious cycle continues.
  • They release product quicker. There are too many API's on the rise to make product integration easier. No need to know how the internals actually communicate between protocols as long as the request send and response received meets your requirement, everyone's happy.
  • Frameworks have a fast learning curve than traditional API's. This is due to the fact that pre/post conditions of using frameworks are lesser than API's and exceptions are "generally" well handled.
Disadvantages:
  • They lack knowledge of internal systems. if you take those who know JPA and Hibernate, most likely they don't understand fully the JDBC API and how the Hibernate framework works internally. They tend to reference a Hibernate/JPA book when issues arise.
  • Debugging is not a strong skill. They haven't been exposed to API when wrong values caused a segmentation fault and a good debugger such as gdb (if you've been a C++ programmer) is a skill. Once stuck in an issue, they are quick to log a issue bug to the company responsible of the framework they use or ask the question to Q&A sites, like StackOverflow.
  • Chances are, they might not be able to write a framework themselves. I don't think they are those people who can write a proper Servlet other than using a @WebServlet annotations (Java EE 6 and higher).

Ask them how the SOAP protocol works and you get an answer like: Get a WSDL, generate client code and write a Service to call a method and bob's your uncle.

I asked one colleague about how to calculate date difference and the first thing I got is to use Joda time. Gone are the days on learning the Date object and doing proper date calculations.

Are they to be blamed?

No! In today's job market, many companies post (development) jobs with requirements that is no more language specific but technology/product specific. A Java developer, today, should know EJB 3, must know any persistent/ORM framework availble (such as Hibernate or JPA), know Business Process Management (BPM) and create/develop using BPMN (like jBPM/Activiti), and know Web Services (RESTful/SOAP).
SOA architecture have taken rise to the IT world, as we see that Cloud Computing, Application in the cloud, and clout services are taking the norm.

If you can't think or find a library that solve a problem on the spot, chances are you won't fit in the modern day programmer.

And what happens to us?

We, the old school developer become Application Support Specialist. We maintain and support outdated but fully functional applications which makes the company its revenue. Are these applications going away? Not likely, but we are not considered in the frame as these new component integrators. Think about it this way, mainframe developers still exists today. They are only available to support the ancient mainframe applications and do few enhancements but don't expect to see a brand new system completely written for the mainframe system.

So, if you decide to further your development career, you should ask: Am I willing to provide service solutions to business or be a technical expert and stay in the daisy wheel of an Application Support Specialist?

Thursday, March 1, 2012

JOAuth 1.3.1 release.

My apologies for the extremely late support and code fix. I have been working on my employer's new project. Seeing that they want to include OAuth on their application, I thought it was a good time to update this library. Hopefully this will be my final JOAuth release (as I've decided to move forward to creating an OAuth framework).

JOAuth 1.3.1 is a release to conform to RFC 5849 strict. This allows OAuth to conform to Strict OAuth Service Providers, such as LinkedIn (which conforms to OAuth1a specification).

The code has been simplified, fixed and included support for HTTP parameters with multiple values (on a key).

I have demonstrated (below) a simple example on how OAuth 1 can be done (using Twitter, of course, as well as Facebook) to retrieve authorization tokens. The former uses OAuth 1 (lenient), while the latter uses OAuth 2 (draft 0). It's up to the developer to understand the OAuth authorization flow.

I hope that you enjoy using OAuth library as much as I had fun working on the fix. JOAuth still has the service to receive authorization tokens (just look at the joauth tag on StackOverflow on how to apply it on yours).


If you have used the previous version of JOAuth, please update your code errors, as some methods on the consumer (particularly OAuth1Consumer) has changed. Oh, did I mention that I Mavenized JOAuth? :-)

Download here.


Enjoy!

LinkedIn Example:



Facebook Example:

Friday, February 24, 2012

Job Security: Threatened by a smarter, junior, employee.

In this economic times, I understand that job security is an absolute worry that consciously/subconsciously brews in everybody's mind (those that are/want to earn income). Oftentimes, this worry brews so hot that it bubbles from a charming man/woman to becoming a hulk. In my case, this hasn't happened (at least, not yet) but I think that is becoming a worry.

The wonderful, true fairy tale story:

Let me elaborate: A company hires a smart, junior, software developer, who has plenty of potential, brilliant ideas and he/she is not afraid to speak his mind about what he/she believes. His/her nemesis (of which the new guy/girl doesn't know about, yet), the experienced senior developer, decides to groom the junior person to learn development best practices and, most importantly, the business.

Over time, the new person becomes valuable to the company: He produces brilliant code, the company's investment on him/her brings results and ROI is good (how to calculate ROI on the employee is beyond the scope of this blog). Now, he has power to object on his senior's decision in problem-solving. 

Sooner (than later), he/she realises that he's mostly on support calls, doing bug fixes and user maintenance of the system application. He's less involved in the new business functionality and he/she finally realises that he thoughts of being a software developer is not what he/she dreamt it was/is.

The nemesis? You've already met him/her. He/she comes to you, once in a while to see if you're working and are busy and you have to kiss his/her behind (as well as his/her manager's). After all, you're getting paid to work, right?

Isn't this frustrating? After years of realising that your skills is being wasted, you decide to leave and you part ways and hope you never come back.

The question is: Why would your "hero"/mentor suddenly become your (unbeknowned to you) nemesis? The simplicity, that I found is this: job security.

Job Security:
 
Job security is the only things that keeps us breathing in this economy. Have you wondered why the sucker colleague, who pleases the manager all the time, climbs easy in the corporate ladder, whereas, you & I, the smart person who has good ideas to bring forward, sits in the "corner" of your desk and screams internally, and hope that someone upstairs might listen?

In South Africa, the "poor" people, who lives by "means-to-an-end" went into an operation called, Xenophobic attack. The operation is simple: Attack all foreigners who are successful. Little did they realise that the foreigners were the same foreigners who sheltered them during the Apartheid regime. They forgot their gratitude and the killing spree began. This was their brilliant idea, to create jobs that they could fill, and possibly to get government to listen to them.

This is how far job security can influence a person.

Job Security for software developers?

 Job security for software developers have taken some weird techniques:
  1. Documentations: Some developers, realising that they feel threatened by the new "kid on the block" or feels like he/she is not worth, they prefer writing bad documented softwares or have little testing in code. This allows them to keep them secure for a while until they keep in their feet and fight back.
  2. Becoming the irreplaceable person: Some become the irreplaceable person. They purposely don't share their knowledge, such that, when he/she leaves, they know they will be re-hired just for knowledge sharing.
  3. Writing a system that looks simple but is complex to understand: Some developers, such as myself, architecturize software to make it simple for other developers to code and implement, but is complex to majority of developers. E.g. using regular expression, it beats 97% of my colleagues. 
Others are mentioned here.


How do I fight back?

So, how do you fight back? Get some boxing gloves, train and invite him/her to a boxing ring and *some text removed to please sensitive readers*! Seriously. I suggest creating an environment where you can thrive and become who you want to be. Start a company.

If you can't start a company, find another job or replace the current nemesis and take his place. This is a competitive world and you have to make the cookie crumble. Never sacrifice your dignity & reputation to please others. I don't and it never got me far, but my time will come.


Now, go back to code!



Thursday, February 16, 2012

StackOverflow: What happens when there's insufficient memory to throw an OutOfMemoryError?

Sorry for the procrastination, I've been doing some work refactoring existing systems at work.

I've recently answered this question on StackOverflow: What happens when there's insufficient memory to throw an OutOfMemoryError?

I will like to thank every developer for your vote of confidence, it brought a smile on my face (now, I know what I was born to do....*movie voice*, lol).

Anyways, I would like to know from other developers (not registered on StackOverflow). If you have other points to point out (outside of what's already posted on StackOverflow), feel free to comment below. 

Let the commenting begin... :-)