Is Online Money Making a reality or a myth?

Fortunately the answer to this question is yes. A resounding yes. I am not going to talk about the details of how to do it but yes it is possible to make money online with blogging. It is not as difficult as it sounds. Here is one simple technique that can get you started: Click to Read

Which is the best method to earn money online?

There are several ways to earn money online. The easiest one is the PPC Method. Write about some topic, throw in some ads and count the dollars. Other ways like affiliate marketing need more efforts, patience and marketing skills.

Are the ebooks sold on the internet about making money online worth?

The ebooks are good but all the information provided there is just a compiled version of the information otherwise freely available on the internet. But they promise too much on their sites. If you find it difficult how to use the marketing techniques like social bookmarking by doing research on the internet using a search engine then you might find such an ebook helpful in understanding the techniques. But it’s nothing more than that.

Yes, you can earn a lot of ad dollars by writing just 5 articles. This may sound ridiculous but it works if you follow this one simple rule:

Use all your writing muscles to write these 5 articles and try to write something unique and useful to the readers.  This may sound too simplistic and something you may already know. But you may not have tried it.

Take your blogging topic and just write the 5 strongest articles and you are pretty much done. Throw in some Google Ads, Adbrite Ads,  Chitika Ads or InfoLink Ads.

These articles are also called as Pillar articles. They form the foundation of your blog. Later you can write small posts that are related to the main topic and which talks in details. These articles are needed if you want to keep coming back to your blog which increases your revenue.

Two years ago there was no shortage of enthusiasm when a sweet little mobile project kicked off.  It was a project for one of the US’s Fire Department (details confidential). Handheld devices were all flown from the US to India. The project began with a development of a web service that provided an API for the handheld Windows Mobile devices to retrieve and submit patient data right from the disaster site to the hospital servers. The paramedics would input the patient data on the field and the bits and bytes would flow to the central servers with whatever means was available at the place at that moment. The software was responsible for detecting which means was available using the capabilities of the device. It could be Wi-Fi, GPRS or even the slower Satellite.

The senior members of the team decided to implement this project in .NET compact framework. Initially I was skeptical but the thought of using core C++ libraries instead of the friendlier .NET compact framework scared me and I kept mum.

The application started with simple data entry forms which were rendered on the fly using .NET’s reflection capabilities. The fact that the forms were rendered on the fly by reading an XML file itched me a bit but again it was time to keep mum because this decision was taken by the US guys and not the Indian architects or developers. I continued to keep mum. As the time progressed through the development and testing cycles, more features were added to the application as the requests came in from the clients. The on-device camera was integrated into the application to take snaps of the patient. The bar-code reader was exploited to scan the bar codes on the patient’s wrists. The project was turning into a software adventure.

The .NET Compact Framework got us started stunningly quickly and the initial features were pretty much ready within few months after starting. Thank you .NET Compact Framework. You filled joy in the hearts of our developers. You are so cool. But deep underground below the compact framework and above the Windows CE – the native mobile operating system from Microsoft- was hatching a deadly conspiracy which would eventually threaten and then actually kill this project. I was becoming aware of it but the team did not care as long as the client was not unhappy.

Then came the grand Stress Testing cycles in which testers would enter data of 100s of patients to test the application. The first signs of internal injuries were becoming apparent. The optimization efforts began. Initial investigation quickly revealed memory leaks in the application. Technically speaking they were not memory leaks but the effect of it was similar to memory leaks. In fact, what was shocking to us was we have to think about the usage of the memory now while the framework was supposed to take the burden of the memory management off the shoulders of the developer on to its Garbage Collector. The promise now seems to be a false one. A promise made to lure developers to use the framework. Moreover, the initial success of the project makes the developer think good about the framework. More investigations revealed that the fault was that of the developer, the developers did not properly dispose the objects. What the hell? It’s a programmers’ fault. I could not believe 100% but I knew the framework has played a game with us. The framework promotes bad programming practices or allows sloppy programming which a C++ environment could not have tolerated right from the beginning.  We were scared now even to allocate even one new string object.  The application was internally bleeding from every side.

Now we knew we needed more memory instantly. Yes the keyword is “instantly”. We wanted to free the memory immediately after use. But the framework did not allow us to do so. Its Disposable protocol meant that the memory will be freed when it thinks it is appropriate. The garbage collector produced spikes in CPU and memory usage when it would run to free memory which we had disposed. By design we did not have control over memory allocations – to be precise – the timing of the memory allocations. Remember we were not building a time critical application; it was just a batch mode application which was not needed to work in real time in the truest sense of the term.

A great application was paralyzed. We could not go back and implement in C++ now. A large chunk of budget was already spent and we were through the development for 2 years now.

Summary: Frameworks are not bad but they produce an illusion of relieving a programmer from the underlying complexity but this complexity attacks back with a vengeance later when the project is in the final stages. A framework like .NET compact framework and some others do have some semi-official documentation available to fix such situations. But this whole thing is really a catch. The frameworks attract you to use it and bites terribly to the extent that project may be rendered unusable. Why not work with the reality right from the beginning rather than start with hiding something as important as memory management? If you do so the benefit is yours in the long run (not very long run). Framework is a silent killer.

Most frameworks rely on the Hollywood principle: Don’t call us, we will call you! This is the root of all the problems. The classic MVC pattern is a great tool, but it is almost always implemented in conjunction with the Hollywood principle (Technically called IOC = Inversion of Control).  This post explains a simple no-framework paradigm.

Based on the theory above, here is what I mean by a no-framework:

1. By all means, follow MVC pattern using either classes or simple file includes. Three different files for M, V and C. (Model, View and Controller) to separate the code into 3 logical parts for easy readability and maintainability (no more separation than this is really required).
2. Include the necessary files in your view file as necessary and call the necessary functions at the top of the view file (this is slightly against MVC pattern because although small amount but some code from controller has crept in the view file) but never mind its simple to understand and teach (The MVC pattern is for us, we are not for the pattern). So it is good to modify a few concepts to fit the needs (Remember we are engineers with limited budgets and unlimited creativity and not scientists with unlimited budgets). Our target is to produce a usable product (forget about reusability – have you ever reused your view/models or controllers?) that is readable and maintainable (and also scalable).
3. Use the “tile pattern” to implement the common parts of the web pages (header, footer, left, right, sidebar, etc.) Put them in separate files and include them where necessary. Most frameworks would not need you to include such things because they hide this from the developers but what is the point in hiding things that are going to ultimately be there? So a framework forces you to “see” what is not visible making it very difficult to understand for a new user. With our no-framework you will not need to imagine things – just keep simple principles in mind.
4. Since there is no Hollywood overhead involved in our no-framework we have a scalable architecture because all we have is the overhead of PHP language itself – no more, no less.
5. Now the advanced questions remain: What about Caching, Multilanguage support and other features that come free with the frameworks? The answer is simple: Learn those things (full stop). Implement them in your code (full stop). Learning these things is good for your health and also inevitable sometime in the future when your framework bites you (and when it is too late and difficult to dig through the framework to fix the weird issues). There is no escape, better face it from the beginning than shying away behind the complicated frameworks that promise great dreams in their feature list.

A few notes: The author is not against the frameworks which have worked great miracles in desktop and mobile applications arena because the interaction between objects is more complicated in those applications and the framework overhead is reasonably acceptable considering the great advantages offered. But this does not hold true in case of the web applications because of the very nature of the way HTTP protocol works. The protocol is simple and so the applications need not be complicated. Show me the most complicated page on the web (a webpage is always simple – it is either a form or a list of records or a simple combination of them). With one web request there is a simple cycle involved from request to the final HTML output delivered to the browser. KISS!

The best frameworks reside in the minds of the developer!

1. Learning Curve: Compared to simple PHP, frameworks need to be understood. Normally the curve is longer if the development resources are not very highly skilled. There are many ins and outs which we need to continuously learn from various official and many unofficial sources. After finding a few issues with a given framework switching to a new framework becomes difficult and also necessary. If a particular thing has to be done in a particular framework which is not directly supported one has to do a lot of research on the web. This is substantial efforts required in my experience. Many times a hack is required which eliminate all the benefits of a framework in the first place (Readability, Structure, Re-usability).

2. Code Efficiency: The time and space complexity of frameworks is not easily controllable. In fact, there is very little control available to the developers over fine tuning of the resources consumed by the framework which may not have been used in a particular project.

3. Total Cost of Ownership: Many frameworks have a great get started video that explains how quick a blog application can be created using their framework. I agree it can be quickly done but there is a catch. This is in compliance with the fact that when something is made easy by a framework it is done at the cost of making something else much harder to do. So even if you get started quickly with a framework, eventually, you are not the winner but a big looser when you see that important things have been sacrificed:

a. Time Efficiency: the code runs slow

b. Ability to support advanced web features.

The point is not just of sacrifice. In fact, there will never be any sacrifice to be done at all. But this comes for a cost, a huge cost. Time and Cost budgets get hampered. The time to market is drastically affected making the whole thing a flop. If, however, the budget is not a concern then one can go for such costly frameworks.

It should, however, be noted that these frameworks come handy when developing very small and simple sites which do not need something unsupported by a particular framework. Finding which framework fits best and supports your needs is a time consuming activity and can be avoided by starting with a no-framework to save this extra time again.

A Good Framework:

From the “engineering” point of view a good framework should consider following realities:

1. Employee Attrition: Employee turnover has plagued the IT industry since long. It is essential that new employees are quickly absorbed into the working teams instead of spending several months training them.
2. Cost Effective: Does your framework increase or decrease your costs? The cost is eventually bore by the clients and not the developers, so it is in the best interest of any customer centric company to use such a framework.
3. Time-to-Market-Effective: Does it save your time or force you to invest your precious time into finding the hacks and “making it work”? This should obviously be the most important concern when choosing any tool.

With these points in mind I have written a small post with some of the simple rules to follow while coding PHP. The framework is in the minds of developer. If a developer is put into the right perspective he understands it and moreover the code has the essential qualities of reusability and readability.