Much to my surprse, last time we had an Oracle sales team in they mentioned that Oracle is now in the business of NoSQL databases in additional to all the other database products they sell.
That is for the data store itself, and doesn't mean that the database is NoSQL or not. MemcacheDB for example is a NoSQL database that uses BerkeleyDB as a datastore. No different than you'd use InnoDB or RethinkDB with MySQL.
Awww.. you mad... I'm so sick of hearing about all these "new" technologies that are so revolutionary, but can't hold a candle to postgres and memcache.
Despite what the brochures tell you, a "degree" from DeVry and 3 hours in a Ruby book doesn't make an architect, and this is one of several "revolutionary technologies", like Ruby, that won't scale and will wither and die.
Exactly, how does a programming language scale or not-scale? Ruby might be slower and hungrier (memory) than other languages but it's the applications that might or might not-scale.
Assuming you have the most efficient code possible, the efficiency and speed of the interpreter can still affect the ability to scale an app.
Another thought is, the interpreter may or may not have scaling / clustering available, be it through a built-in functionality or an external queue or something.
Sometimes we have to code around interpreter/speed issues. I work in the JVM languages sometimes. I have to do things differently directly in Java if a particular JVM language I use isn't cutting it. Same goes for ".NET", which is over 30 some languages.
Go ahead and write your self-congratulatory blogpost when Ruby "withers and dies". If HN is still around in 40-50 years, I'm sure it'll hit the frontpage.
This is a terrible hit to the team. I lost one of my co-founders at a very young age.. Brandt Cannici was his name, and we really never recovered from the loss. My condolences and best wishes to his family, friends, and the Diaspora team.
I assume you are afraid of reprisal from Google by not mentioning which application(s) they allegedly removed. When trying to rally support, more evidence is better than less, more detail better than none.
My expectation is that people assume people get what they deserve and/or don't care what happens to other people so long as it's not them or the people they personally know and care about.
This is more about sharing a story of a behavior which I had no idea Google practiced. Will it be ignored? Probably.
first.. identify their role, and yours. Be clear about it. It's the first thing they'll ask you after you tell them what the company will be doing. The lines need to be very well defined, especially if you don't know this person, so that the roles don't conflict.
Before you "find" one, do the above. Then repost :)
Google licenses the data, but has the resources to acquire the data, and the company that owns it. If you go to the vendor and try to license the data, the cost is now so high that a startup without funding will be unlikely to afford it.
With the exception of "employees", you are correct.
Each is a single point of failure that should be considered, each with its own set of criteria. If there is a sufficient supply of vendors, then the single point of failure (or sourcing in this case) does not pose a threat to your "business".
In the event where the payment processor keeps your customers credit card information, for example, you risk losing your customers when you have to go back to your customers to re-acquire the data should the provider cease to exist, or their policies prevent them from being used. This can be mitigated by using gateways that don't hold the data (like PayPal) as an exclusive processor, and managing that data yourself.
Risk mitigation should be applied to every aspect of your business that has a reasonable risk of becoming a choke point for operations.
Google licenses the data for the same reason you do -- because creating the kind of business they want to create is prohibitively expensive to do otherwise.
Google has resource constraints too. They can't pour billions of dollars into their Maps product (or any other product) just because it's cool. There has to be a reasonable return. And just because they're operating at a different scale as you doesn't change the fundamentals.
| And just because they're operating at a different scale as you doesn't change the fundamentals.
What? Which fundamentals?
Google licensing the data from the provider doesn't make it less expensive for anyone else, it makes it more expensive. They get exclusive licenses that allow them to resell access, thus removing a potential vendor from the pool of possible vendors, and making Google ultimately the only vendor available as they tie up the access points.
I suppose as long as you're okay with Google controlling your access to the information you require, full steam ahead.
That still doesn't change the fact that you no longer control the future of your business. If that's the path you choose, Google owns your business. If they decide to deprecate the very data your business depends on, you're done.
Except that throughout the years, the manufacture of cars has become commoditized, and there are many more engine manufacturers than there were, so it's virtually impossible for a single manufacturer to corner the market on engines. Additionally, since the parts can all be fabricated by a multitude of vendors, there's no risk to the car company of a single point of failure.
It's about risk mitigation as it pertains to the use of third party APIs. I believe there are too many startups basing their businesses on the APIs of others.
Had I simply written about risk mitigation, it would have been up to the reader to apply it to the use of API's, which clearly startups are not doing.
With respect to the use of those APIs as a core business function, the viability of their continued use is only as secure as the CEO of the company that offers them is honest.
If history is any measure, that's not very secure.
Sure. I've programmed PHP for the last 8 years, and C/C++ for 18 years before that. A few months back I picked up Python in about 5 days, dabbling part time. Django on top of Python took another day or two.
I now consider myself an advanced Python developer. It's actually much easier than PHP, but the lack of curly braces, and strict adherence to MVC were my initial hurdles.
I can't imagine going back to PHP at this point, even though everything I did in PHP was highly object oriented.
It does have an issue I find significant, which is the Views being a mix of logic and templating. I find this messy and contrary to the original MVC pattern, since it pushes too much presentation code to the controller (it has to decide what formats to present the data in, for example).
But with KOstache[1], a Kohana module, you get your real Views again, along with logicless maintainable Mustache templates. Win/win.
