Skip to main content

Posts

GST for IT and ITeS sector

Goods and Services Tax (GST) is a destination based consumption tax. It has been designed in a manner so that the tax is collected at every stage and the credit of tax paid at the previous stage is available to set off the tax to be paid at the next stage of transaction, thereby eliminating cascading of taxes. This eradicates “tax on tax” and allows cross utilization of input tax credits, which benefit the industry by making the entire supply chain tax neutral. The purpose of this write-up is to provide overview of GST  for Information Technology (IT) and IT enabled Services (ITeS) sector/industries.   ·    GST ends historical issue of software classification :  Under previous tax structure, the sale of packaged software was entitled to both VAT (approximately 5%) and service tax (15%). The VAT on sales is directed to the state government whereas the service tax on service follows the central government. Also, there were cases where along with the VAT a...
Recent posts

How to secure your chat and messages in Gmail

We, (at least me) have so high regards for Gmail that it always uses a secure connection (https), BUT that not the truth !!! The secure connection (https) is used only when we login, so our password is safe. After that, Gmail switches back to normal http connection and all our messages and chats goes in plan text. Anyone can sniff it. How to secure your chat and messages in Gmail: 1. Login into Gmail -> Settings -> General -> Browser Connection, Select "Always use https". PS: There is no free lunch. This setting will slow down your Gmail connection a bit as all the data now going in encrypted format.

Object Oriented Design - Rob Pike View

OO is great for problems where an interface applies naturally to a wide range of types, not so good for managing polymorphism (the machinations to get collections into OO languages are astounding to watch and can be hellish to work with), and remarkably ill-suited for network computing. That's why I reserve the right to match the language to the problem, and even - often - to coordinate software written in several languages towards solving a single problem. It's that last point - different languages for different subproblems - that sometimes seems lost to the OO crowd. In a typical working day I probably use a half dozen languages - C, C++, Java, Python, Awk, Shell - and many more little languages you don't usually even think of as languages - regular expressions, Makefiles, shell wildcards, arithmetic, logic, statistics, calculus - the list goes on.

Unix programming style simplified

Unix programmers divide all programming into three parts -- policy, mechanism, and glue. Mechanism is code that tells how to do things, policy is code that tells what to do -- and glue is the stuff that binds policy and mechanism together. The punch line: glue is evil and must be destroyed, or at least minimized. Your typical huge honkin' C++ application with classes stacked twelve deep is an un-maintainable mess because the top two layers are policy, the bottom two are mechanism, and the middle eight are glue. And the trouble with glue is that it's opaque -- it impedes your ability to see clear down through the system from the top, or clear up from the bottom. You can't debug what you can't see through, because you can't form an adequate mental model of its behavior. This is very closely matched by the separation of mechanism, policy and glue. "Mechanism" is roughly equivalent to the data "model", "policy" is roughly equiva...