<?xml version="1.0" encoding="utf-8"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>Cuelogic Technologies - Latest Comments</title><link xmlns="http://www.w3.org/2005/Atom" rel="http://api.friendfeed.com/2008/03#sup" href="http://disqus.com/sup/all.sup#forumcomments-39aefe38" type="application/json"/><link>http://cuelogic.disqus.com/</link><description></description><atom:link href="http://cuelogic.disqus.com/comments.rss" rel="self"></atom:link><language>en</language><lastBuildDate>Wed, 07 Apr 2010 02:56:35 -0000</lastBuildDate><item><title>Re: Building a scalable &amp;#038; secured product using Open Source Technologies and Software</title><link>http://blog.cuelogic.co.in/?p=7#comment-43620156</link><description>Vikrant,&lt;br&gt;&lt;br&gt;Very nice article. You have very precisely mentioned the important decision making points while opting for open source technology. And Narayan, your comment was the cherry on the cake. I have seen (younger ;)) programmers considering themselves PHP experts, because they have done 3 Drupal installations.&lt;br&gt;&lt;br&gt;Also, it is very important for product owners to understand that open source software basically just provides you access to the source code which you need to develop based on your requirements. And this lack knowledge is not among only the non-technical decision makers.These myths about open source are also common among technical guys working in other technologies. &lt;br&gt;&lt;br&gt;Some days back I was asked by a very senior IT professional if we can build a Facebook clone in 8-10 working days, because everything in open source is free and available. So why would development take time? It is like trying to build Eiffel Tower in a week, just because steel is freely available.&lt;br&gt;&lt;br&gt;So hopefully your article will help more and more people understand the very basic meaning of 'open source'. Looking forward to more of these. Cheers!!</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Abhijeet</dc:creator><pubDate>Wed, 07 Apr 2010 02:56:35 -0000</pubDate></item><item><title>Re: Working with Startups</title><link>http://blog.cuelogic.co.in/?p=24#comment-43519003</link><description>You make some very interesting observations about adjusting your expectations when working with start ups. This has been my experience as well. I keep my rates low but receive equity participation with each engagement, usually in the form of a promissory note equal to or twice the value of the retainers I receive. The note is only executed upon a liquidity event. Not every start up succeeds but this way I can recover the loss of deferred income when one does succeed. You really do become part of the organization's DNA. In many of engagements the term lasts well beyond 3 years.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">lenrosen4</dc:creator><pubDate>Tue, 06 Apr 2010 14:16:12 -0000</pubDate></item><item><title>Re: Building a scalable &amp;#038; secured product using Open Source Technologies and Software</title><link>http://blog.cuelogic.co.in/?p=7#comment-43290468</link><description>"Another issue which is prevalent is that the new breed of programmers or freshers who enter the market have started assuming that tools like Drupal, Joomla etc. ARE the technology." - This is perfect point Narayan. The problem is 360 degree communication, we as a professional never turn back to our colleges or institutes and try to educate students about the technology we are working at. This is the problem of our education system as well. Student never faces the reality during there academia. Very soon we are going to start 360 degree communication where fresher will come to us and become the professional.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">cuelogic</dc:creator><pubDate>Mon, 05 Apr 2010 05:10:00 -0000</pubDate></item><item><title>Re: Building a scalable &amp;#038; secured product using Open Source Technologies and Software</title><link>http://blog.cuelogic.co.in/?p=7#comment-42842118</link><description>Vicky,&lt;br&gt;&lt;br&gt;You have hit the nail!. What you say perfectly makes sense.&lt;br&gt;&lt;br&gt;Kudos to you for such a nice article at the right time!. This article can go a long way in educating service providers as well as buyers about choosing the right technologies and tools for meeting their business requirements.&lt;br&gt;&lt;br&gt;We are in an era where people are looking at acquiring top quality software at a very cheap rate. Its like asking for the best of both worlds!. They usually are not able to analyze the trade-offs involved in choosing the right platform/technology. There are many reasons for their hurried decision-making some of which include COST factors, positive hear-say about certain Open Source tools, pressing deadlines, bias towards any technology or tool, preferred vendors, first impression about any tool/technology and lack of faith in technology as a medium of advertisement, to say the least. We as vendors have to throw light on helping them choose the right technology/tool for their business needs.&lt;br&gt;&lt;br&gt;Every project, as you have rightly said, has to be dealt in the context of its requirements ONLY. There are tons of generic tools which give us an illusion of fully catering to ANY kind of 'related' or 'almost the same' requirements. In the first place, these tools were never built with the aim of catering to ALL kinds of requirements. So our assumption that such tools can be customized endlessly and shape it to meet the clients' requirements, is wrong. Though experts may be actually capable of doing this but in the end they would have spent the same time as would have required in building something from scratch. So then they would have achieved very little by customization of such tools. &lt;br&gt;&lt;br&gt;One more aspect I have seen is that programmers tend to lean more towards the features provided by a tool rather than the features required by their clients. For ex. when a programmer tries to provide a solution using Open Source tool, and if they are not able to tailor it as per the client's needs they end up convincing the client about the impossibility of the tool to cater to their needs or mislead the client into some feature (existing in the tool) which is useless for the client, as a compromise. &lt;br&gt;&lt;br&gt;Another issue which is prevalent is that the new breed of programmers or freshers who enter the market have started assuming that tools like Drupal, Joomla etc. ARE the technology. They ignore the fact that if they want to be known as good programmers they should learn the ACTUAL technology which is used to build these tools. So this is another down-side of depending too much on such Open Source tools. &lt;br&gt;&lt;br&gt;I would any day advocate usage of certain popular PHP based frameworks like CakePHP, Zend Framework, Symphony, CodeIgniter rather than just leaning on Open source tools. These frameworks actually shape the way people code and can help programmers establish their base. Using this base they can adapt to any tool in that technology. Though sometimes the overheads involved in deploying such complex frameworks for all volumes of projects may be more compared to the returns but in the long run I am sure it would be definitely beneficial from a quality and growth perspective. &lt;br&gt;&lt;br&gt;To summarize, I would recommend partial dependency on open source tools wherein we don't need to reinvent the wheel and thus reduce development time and cost. However the importance of putting time on planning and designing the product/project architecture should not be ignored as that is how we learn and achieve specialization on technologies.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Narayan</dc:creator><pubDate>Fri, 02 Apr 2010 03:19:52 -0000</pubDate></item></channel></rss>
