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
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.
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:
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.
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.
A mobile website is designed and optimized for browsing on a smartphone – the likes of iPhone, Nexus S, Z10. They come in various flavours: sometimes there are different desktop and mobile versions, other times they are the same. The focus of this article is on those websites that are specifically designed for “enhancing the mobile user experience“, although more often than not, it has the exact opposite effect.
The sins presented in this article are so common that you should be able to relate to them. The most common complaints people have – or the 7 Deadly Sins of Mobile Websites – are *drumroll*:
I have decided not to sound like a broken record. Instead I will leave you with this rather fine point to ponder: A percentage (*1) of users browsing mobile websites are using slower connections like EDGE or 3G, not the fast Wifi we have in our homes and offices. So while a website may take 4 seconds to load on desktop, it might take longer than that to load on the mobile.
Websites guilty of this vice try to cram too much
un-necessary text to look busy, put happy talk (“Welcome to my sweet, lovely website“) or what I like to call “me” talk (“We are very happy to receive the elusive Greatness-Trophy thanks to the hard work and dedication of our CEO“). The average user who arrived on Acme Widget’s website to check hours of operation don’t give a fat f*ck about their head of marketing’s epiphanies .
In real life, we like people who are articulate. They speak fluently, coherently and get their thoughts across in a concise manner. Why should websites be any different? The Great Leonidas, couldn’t have been more more clear in delivering his message to the Persians.
In three word response: “THIS IS SPARTA” followed by an epic kick into the bottomless well (*2) in the movie 300, he gave the most kick-ass message of all time.
In my next post, I will discuss some of the ways to avoid this.
Hidden menus, hover objects, small buttons, small radio buttons, buttons that are too close to each other, the list goes on. Imagine, you’re travelling in municipal bus which is jerking you around like no roller coaster would while you are trying to post a comment to the just-posted wise meme. But you can’t seem to click on the “Post Comment” button. Every time you try, it opens the link besides that button – every link left or right seems to work and no matter how hard you try, you just cannot press the damn button. And who do you blame for your misery – there’s only one culprit – your. fat. finger.
In fact, the fat finger syndrome is so prevalent, that people with fat fingers have started an organization to protest this and have equal rights when it comes to web accessibility as everyone else. The organization is aptly named “The Association of People with Fat Fingers” or APFF.
Often times, the mobile website looks so different from the desktop version that users start wondering if they are on the right website. Worse still, if the mobile website has a very different layout and content, it’s like asking users to go over another learning curve. No thanks.
Ah, the joy of having a huge box in front of my face telling me how good the App is and I should get it from the App Store. The irony: already have the steaming pile of sh*t app installed and much rather use the website. How about I just leave instead?
Chris Lake makes some compelling points against the Popup Syndrome, summarized in this fantastic statement:
A link should be a promise: you click one to be taken to a specific page. That’s just how it is, and it’s what every web user expects (unless programmed to expect something different, e.g. Forbes, which I no longer visit). Websites that lead you down the garden path before fulfilling the promise only serve to disappoint users.
Need I say more? Popups are so bad on mobile websites they should be banned altogether and erased from existence. JQuery’s author should be forced to take a oath at gun point to stop supporting these or else…? Exactly.
At first, it sounds like a novel idea: redirect users to mobile optimized or iPad optimized website based on the type of device/browser they are using. If done right, that is, you have a great mobile website e.g. Boston Globe, BBC, it’s a great idea. The problem is when the mobile website sucks (guilty of 7 sins), users who want to use desktop version will get agitated if they don’t get what they want. They will get very annoyed if even if they are asked to make the very important decision to choose between “The Mobile Version”, “The Desktop Version”, or “Get the App” every single time.
But what makes auto redirect an absolute sin is faulty redirects. As Yoshikiyo Kato writes in this post:
A faulty redirect is when a desktop page redirects smartphone users to an irrelevant page on the smartphone-optimized website. A typical example is when all pages on the desktop site redirect smartphone users to the homepage of the smartphone-optimized site. For example, in the figure below, the redirects shown as red arrows are considered faulty:
In fact, faulty redirection is so bad that there are reports suggesting that Google penalizes websites guilty of this sin in terms of their page rank.
Oh, and faulty redirection also makes private browsing inconvenient.
How could anyone ever even think about jamming in bunch of advertisement even with that much limited screen real-estate? Some people think putting banners on websites is a wise idea. News Flash – Banner ads are trouble. This is 2013, not 1999.
Banner ads suck say guys who invented banner ads. Nuff said.
There you go folks – That’s all. If you know someone who is guilty of committing any one or more of these cardinal sins, may be it’s time to chastise them and show them the light.
Dec 27, 2013 – Matt Welsh disagreed that vast majority of users access mobile sites via cellular network. I’m not sure but since I cannot find any data, the original comment is posted below for you to decide.
“This is a nice article, but I disagree with the statement that “most of the time”, users are accessing the mobile web via cellular (not WiFi) networks. The data that I have seen on this is that the vast majority of mobile web usage is via WiFi – more than 70-80% of mobile pageloads occur on WiFi networks. (Context: I run the mobile web performance team at Google, part of Chrome.) This is in part because web usage is higher on tablets than on phones, but even on phones we see WiFi being the most commonly used network by far. This is not to say that cellular performance isn’t important, but this skew might be somewhat surprising to people working in this area.”
*1 = See Updates (Matt Welsh) *2 = Yes, I know it wasn't bottomless since Leonidas clearly said "Earth and Water, you'll find plenty of both down there".
In the post on stopping threads, we looked at how to design threads that could be stopped. Turns out, there’s only one way to do this: via interruption and cooperation from threads themselves.
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 task it 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:
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.
Provide a custom ThreadFactory to the ExecutorService. Return custom Threads which override the interrupt method. For example:
Overriding interrupt() method is not recommended.
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, my company gave me go ahead to build an offshore team – Due to the nature of our work and timelines, we are terrified of employee turnover. Instead of reaching out to an existing offshore development firm (due to our sour experiences in the past), we decided to setup our own. I will discuss the pitfalls and share my experiences of building such a team in another post.
In this post, I would like to talk about my experience hiring offshore workers. In total, we hired 9 offshore staff in 2013, out of which 2 left, bringing our employee turnover to 22%. However, the costs of replacing these workers were in the ballpark of few thousand dollars since they left early enough in the project – not considered a red mark.
Let’s talk about the 4 most important qualities to look for in offshore workers:
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.
The second most important quality you should look for is communication.
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).
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.
An open-source software project for sharing data between distributed applications. It acts as a “coordination” service for distributed applications to synchronized with one another.
In a nutshell, ZooKeeper gives you the tools to help build distributed applications. For example, suppose you have a distributed web server application running on 10 nodes. Say, you want to get total real-time hit count. One way to do this is to write an application which connects to the 10 nodes, gets count from each and present the sum. Alternatively, you can have each web server application write their hit counts to ZooKeeper on regular intervals and then query ZooKeeper to get the count.
ZooKeeper supports locking, synchronization, queues, hierarchical naming service and much more, out of the box.
ZooKeeper runs on a cluster of servers. Data is replicated on nodes and is kept in memory. Clients can connect to any node to read and write, however, writes are passed to the cluster `leader`.
ZooKeeper is eventually consistent: the writes are guaranteed to be executed in the order they were received from the client, updates are atomic, and will eventually be replicated to other nodes.
ZooKeeper is widely used by some big names such as Yahoo!, Netflix, Twitter, and LinkedIn.
I have used Redis in the past to coordinate and share data between our distributed applications. Redis is much faster than the ZooKeeper and extremely simple to setup. However, the issue with Redis is that it is not truly distributed in itself and problems may occur if the main Redis node fails (Although, I have been hearing about Redis cluster coming soon. Haven’t tried it though). I don’t want to get into Redis Vs ZooKeeper debate, but if you want to automatically recover from failures, use ZooKeeper. If you are sharing a lot of data at a very high rate, and you can tolerate some downtime, use Redis.