Post moved here: http://codeahoy.com/2016/04/03/effective-code-reviews/
java.lang.Thread class is used to create threads in Java. All code in Java executes in the context of some thread.
Source: Java Threads in 60 Seconds
Very good tax advice for startups.
Tax deadline is just around the corner. Sometimes even a straight-forward individual return can be quite a challenge. Things get more interesting when you add the business complexities associated with a small business or a startup. For many new entrepreneurs, filing taxes can be a real learning curve.
Most of us are aware of IRS audits and the associated pains. But what most entrepreneurs don’t realize is that they often overpay Uncle Sam by committing small mistakes and overlooking various tax deductions.
Keep on reading to discover common tax mistakes startups make and as a result leave hundreds, even thousands of dollars off the table — and how to avoid making them yourself.
Don’t Overpay Your Taxes – Mistakes 1to 5
In the SlideShare presentation below, we’ve listed 5 common tax mistakes startups (and small-businesses) make. Enjoy the slides and save yourself money, time and headaches.
So the main takeaway from the presentation is, and we cannot…
View original post 641 more words
Couple of days ago, I received a link from a colleague to an article. The author talked about how his company declared war on paper by taking extreme measures such as hiding printers in hard to find places and getting rid of toilet paper from bathrooms (they installed Aqua Clean WC which cleans with water).
Gotta love the modern workplace.
While I cannot think of a scenario where the use of paper should not be avoided, the reality is that paper is an important part of our modern society. It touches our lives in so many different forms – receipts, contracts, checks, warranties, packaging, lecture notes, passports to name a few.
Whether you need to store receipts for expense or tax purposes, or you love the tangible feel of taking lecture notes on paper, here…
View original post 507 more words
Must have apps for scanning and digitizing those receipts you’d need later. Scan it and toss it in the bin.
Scanning a document used to be tricky in the past – you had to access an actual scanner, load the paper and wait 10 seconds or more for the scanner to finish scanning.
These days, converting a document to PDF is almost hassle-free and doesn’t require a clumsy scanner. The apps we’re going to review in this post make scanning a breeze. The principal concept for all the apps is the same: you snap a photo of the document from the app, it detects document edges and enhances the image to look and feel like paper and exports to PDF for sharing.
It’s no surprise that CamScanner is at the top of this list — they have the largest number of users (about 50 million). Although there are lots of great features, the two best that I absolutely love are: 1) Excellent algorithm for detecting document edges inside…
View original post 247 more words
CPU Express Inc, a chain of computer & laptop stores, had decided to develop an in-house software for managing customer accounts and inventory. The reason was really simple: save costs. The software was designed to handle backend tasks – requests came to it over store’s network. Requests were:
- Check for an item in the inventory
- Query customer account balance
- Update customer account balance, etc.
Inventory and accounts information was stored in an enterprise grade database from Coracle Corp.
The software was designed and developed by CPU Express’s Chief Developer. Rob was in his mid 20’s and was a reasonably good looking guy.
Version 1 was a stand-alone command-line program that accepted events from clients, processed them, read and wrote to the database and sent responses back. While Rob developed and deployed the system in record time, he knew something had to be missing.
Then one evening, he received a phone call from the head office: “The requests are not going through. Something’s wrong…“, said Operations Manager. Rob rushed back to the office and discovered that an uncaught run-time exception on a rare malformed request had brought the system down. The system was single point of failure. Rob started thinking and realized that the system needs redundancy and with 6 new stores set to open soon, ability to handle extra load without affecting response times.
Rob went back to the drawing board with two design goals: redundancy and scalability. He got a good idea that he could implement with minimum changes to the existing system: run the system on multiple computers and write a very thin layer of software to receive events and divide them evenly between the two applications. He could now add more servers when the demand grows – i.e. scale out. Also, as long as at least one server is up, the system stays functional. And so he released version 2 with these changes.
A few months pass. CPU Express Inc. not only became cash flow positive but saw a rapid growth in their business model. The CEO wanted to compete with the big guys and start selling computers online to customers from coast to coast.
Rob recommended a 3rd party tool, Rad-Sell, for their online store. But there was a little problem – The General Manager, a seasoned skeptic, didn’t want to allow a 3rd party to have access to the main database. This was a potential deal breaker: Rad-Sell needed a way to access inventory to check and update.
Rob put on his thinking cap and had his eureka moment: all inventory related code in the main application was in its own package and decoupled from rest of the code. “I could extract and reuse the inventory code and turn it into a stand-alone application. That way, it can ‘service‘ requests from other systems…” yelled Rob. He went straight to work. To accept inventory control requests, Rob had to define a format or ‘protocol’ that both Rad-Sell and his software could use. After much deliberation, he settled on XML.
Other pros of this approach are: inventory service’s code can be updated and other systems won’t notice a thing as long as the ‘protocol’ for receiving requests isn’t modified. Testing and debugging smaller services is easier than one large, monolithic system. Services could be better scaled by adding additional servers to run services that require more horse power.
Rob liked this approach so much that he took it a step further – he identified other components in the main application which performed substantial actions, such as Credit Fulfilment, etc. and turned them into ‘services’. When all was said and done, the original system Rob had developed was left with nothing but business rules and relied to services to do actual work, such as inventory check or marking an item as sold.
Summary and moral of the story
Rob started with a tightly coupled client-server model. To keep up with the throughput, scalability and fault-tolerance demands, he unknowingly arrived at an architectural style known as the “Service Oriented Architecture” or SOA.
We’ll review SOA in Part 2.
In the previous post on stopping threads, we explored thread design strategies to safely stop threads in Java. In this post, let’s look at various ways we can stop or cancel tasks handled by Executors (and ExecutorServices).
When we submit a task (Callable or its older cousin Runnable) for execution to an Executor or ExecutorService (e.g. ThreadPoolExecutor), we get a Future back which wraps the tasks. It has a method called cancel(…) which can be called to cancel the taskFuture wraps. Calling this method has different effects depending on the stage the task is in. A task could be in three possible stages after being submitted to an Executor:
- The task hasn’t started executing yet – it is waiting in the work queue for a thread to start executing it.
- A thread is executing the task.
- The task has finished executing.
Cancellation is trivial, if the task hasn’t started executed. It is simply removed from the work queue. Similarly, if the task has finished executing, cancelling it has no effect.
It is a little tricky when the task is executing in a thread. Recall from my previous post: to stop threads in Java, we rely on a co-operative mechanism called Interruption. The idea is very simple. To stop a thread, all we can do is deliver it a signal, aka interrupt it, requesting that the thread stops itself at the next available opportunity. If the thread cooperates, it will clean up itself and stop. Non-cooperating threads ignore the request and cancellation will have no effect.
boolean cancel(boolean mayInterruptIfRunning)Attempts to cancel execution of this task. This attempt will fail if the task has already completed, has already been cancelled, or could not be cancelled for some other reason. If successful, and this task has not started when cancel is called, this task should never run. If the task has already started, then the mayInterruptIfRunning parameter determines whether the thread executing this task should be interrupted in an attempt to stop the task.
So when the tasks is already executing and we call cancel(true) on it, it will deliver an interrupt signal to the thread executing the task. In order to make this work properly, your threads must be designed to handle interruption. Refer to this post for more info.
Sometime, it becomes necessary to support non-standard task cancellation – especially when the task relies on blocking or long-running methods that are oblivious to interruption. E.g. when you call ServerSocket.accept(), it starts waiting for a client connection. The catch-22 is that it will ignore all interruption requests and if this function is called in a thread, you cannot stop that thread using interrupts. To support nonstandard cancellation where interrupts won’t work, there are two ways of doing it. Please remember, in both of the following ways, you will have to do something to cancel the method that ignores interrupts. E.g. in the case of ServerSocket, closes the underlying socket which forces the accept() method to throw an exception.
1. Overriding Thread.interrupt():
Provide a custom ThreadFactory to the ExecutorService. Return custom Threads which override the interrupt method. For example:
Overriding interrupt() method is not recommended.
2. Overriding Future.cancel(…):
In your tasks (e.g. Callable) provide a method for non-standard cancellation, such as cancelTask(). Then override the Future.cancel(…) to call cancelTask().
But think about it: We do not normally create a Future ourselves and specify what the cancel(…) method does: we get Future when we submit a task to an ExecutorService via ExecutorService.submit(…).
Luckily, ExecutorService calls on a method called newTaskFor(Callable c) that returns the Future (or rather RunnableFuture) representing the task. Hence we need to override newTaskFor(…) to return a custom Future which overrides the cancel(…) method. This is shown below with an example:
Whereas the IdentifiableCallable is shown below:
Next we need to define our own FutureWrapper so we can override the cancel(…) method:
Now we need to define our task as follows:
That’s all. Now when we call FutureTaskWrapper.cancel(…), it will in turn call cancelTask(), where we can do our non-standard cancellation.
The entire code used in this post is available on GitHub.
Here’s my top ten list of the books I managed to read in 2013.
1. Don’t Make Me Think by Steve Krug – One of the best UI/UX design books I have ever read. Short, to the point, easy to read with lots of examples. While an excellent book, it first came out in 2001 and then in 2005, so some web design suggestions may be dated. It’s not about how to add pizzazz to your site by applying lipstick but how to make websites that are usable and doesn’t force users to think.
2. Endurance – Shackleton’s Incredible Voyage by Alfred Lansing – A compelling account of Shackleton’s incredible, but doomed voyage from England to the southern Antarctica. Heartwarming story of Shackleton’s courageous leadership skills that allowed his lost crew to survive bitter cold, darkness, constant danger for months. Highly recommended for anyone aspiring to be a leader.
3. The Snowball: Warren Buffett and the Business of Life by Alice Schroeder – I picked this up at local Chapters without knowing what to expect. Turned out to be a very good find. From an early account of Buffet’s life in Omaha, his childhood, influences, and decisions that made him the best investor in the world that he is. My only complain is that the book is huge!
4. Peopleware by Tom DeMarco – Amazing, fantastic, mind blowing guide on managing Software teams. Non-conventional, no non-sense approach to management. Couldn’t recommend it more for anyone who is a Manager or aspiring to be a Manager. In fact, it should be made compulsory for all managers to read this book every quarter.
5. Salem’s Lot by Stephen King – Not a big fan of horror fiction, but this was a great story. Spoiler Alert: Dracula in a small, sleepy New England town.
6. The Five Dysfunctions of a Team: A Leadership Fable by Patrick M. Lencioni – An excellent leadership book written as easy to read story about a dysfunctional team in an imaginary Tech company in the Valley. Short and sweet: could be read in two or three sittings.
7. Hadoop: The Definitive Guide, 3rd Edition by Tom White – An excellent resource for anyone wanting to learn Apache Hadoop. Hard to read cover to cover, the first few chapters are an excellent introduction to Hadoop. Staying on my reference shelf.
8. How to Win Friends & Influence People by Dale Carnegie – I’ve been meaning to read this book for years now. Reading about it in “The SnowBall” and that Warren Buffet went as far as enrolling in Carnegie’s seminars convinced me to finally buy it. I’ve not much to say other than it is a good book.
9. Programming in Scala by Martin Odersky – I’m into functional programming and like Scala. This is the best book on Scala written by the same homely genius who created Scala. He also runs a free online course on Scala on Coursera which I also highly recommend.
10. Enterprise Integration Patterns by Gregor Hohpe – Patterns on integrating enterprise applications using messaging and asynchronous communications. Kind of old, but very good book for understanding and building solid concepts.
In 2013, I hired a total of 9 people for our offshore software team. Earlier, we were working with couple of “offshore software development” firms and the experience was generally positive. The biggest problem was employee turn-over: it turned out that most of these “offshore firms” weren’t paying their people enough and didn’t treat them well. As a result as soon as guys had better offers, they jumped ship. Long story short, we decided to build our own presence and directly hire people – I wanted to build a healthy culture and have employees that were engaged and quality conscious.
The initial experience wasn’t great. I hired some complete bozos (I didn’t have a good hiring process) and at one point had to almost 30% team go. But by the end of the year, we ended up with a good group of people who were delivering great quality code. In this post, I would like to talk about 4 qualities you must look for when hiring offshore developers.
Quality #1: Communication skills
The #1 quality to look for in offshore staff is their communication skills. I cannot stress it more. If you’re hiring offshore staff only on the merit of how they performed in the technical interview, you are doomed. Think about it: any serious software development is seldom done by a single person in isolation. If you work for a startup, you might disagree with me… but only for a while. Sooner or later, there will be more people, more inputs, more suggestions (alas, more bureaucracy)
It is mandatory to setup proper communication channels, like Skype, scheduled meetings, conference calls, but it is not enough. If the offshore developer doesn’t have good communication skills or shies away from communication, it will become very challenging for the manager and the onsite team to understand where exactly they stand and the technical issues they are facing.
Drawing from experience, my first offshore hire was a young, fresh graduate. During the interview, she blew my mind the way she answered some of the technical Java questions and her deep understanding of concepts. But I felt like I almost have to force her to answer my questions: she was very, very quiet. May be it was just cultural, may be she was just scared, or was simply too shy. I ended up hiring her based on her technical skills – and the communication soon became the biggest challenge – It started taking a toll especially on on-site developers who could only talk to her at odd times and I made a decision to let her go.
I would suggest asking the potential candidate to talk in depth about the project he or she last worked on. Let them talk and see if they can describe in clear language using proper technical jargon. See if they are enthusiastic or dry. Let them talk: you shut up and listen.
Quality #2: Communication skills, again
The second most important quality you should look for is communication.
Quality #3: Flexibility
It’s a challenge working with teams in different timezones. Your offshore developers must be flexible and willing to be available at odd times occasionally. It’s not enough to set fixed schedules: I can guarantee that sooner or later, you’d want them to be available on a call with a vendor who is in a different continent than both you and your offshore team. If you have people who start whining and complaining about meetings at odd times, you should let them go and wish them luck finding a 9-5 desk job.
I would advice being upfront and discussing this in the interview. You should also assess candidates for their flexibility: for example, an older developer with 3 kids is less likely to be flexible than someone who graduated 2 years ago. I wish we had followed this advice when we hired a senior Java developer: great guy, but high maintenance and slightly Prima Donna. I normally tolerate high maintenance as long as people are good at their craft – However, this guy made it clear that he will work only from 9-5 since he has other “commitments” in evenings, no exceptions short of an absolute emergency. Meetings became exasperating since the only time he was available to talk was from 10pm to 6am, local time.
But try to be fair to the offshore team: if you are day and night away, like USA & India, have half or quarter of the meetings in your evenings (morning there) and the other half in your morning (evening there).
Quality #4: Ownership
Extremely important, but also the most difficult one to find, is hiring people who’d take ownership. I’m not saying they take ownership of the entire project, but at least of the task assigned to them. If you find yourself babysitting your offshore worker after 5 months on the job, either you are not fit to be the manager or you don’t have the right person.
Ideally, you want people who could be considered a nuisance: to get their answers, they will haunt you like bloodhounds. They will keep messaging you until they get their answer. These people are like animals. Believe me, you NEED them.
Finding such people is very challenging: chances are you will come across them only by luck since it is very unlikely that their current employer will let them go. However, whenever you get the luck of the draw, pounce, keep and do your best to retain these people. A few of these people will even make an average team look like superstars.