26 karma · joined May 12, 2011
https://github.com/pamelafox?tab=repositories
https://github.com/kellabyte?tab=repositories
https://github.com/gwenshap?tab=repositories
See? Any of those smart women above has much more quality code in their repos with regular activity, even though not any of them works at github, that is, they push code on their free time.
Finally, let's see a repo by another harassed geek girl: https://github.com/adriarichards?tab=repositories
Um... I definitely see a pattern here screaming too loud not to take notice.
But, seriously, I know various female programmers that I could trust not only my project, but my LIFE to. And as in the case of men, those are usually the low profile, highly productive, people. I doubt any "famous" developer this days in spite of gender/race/whatever. As with any hyped profession, there are a LOT of impostors trying to succeed without basic qualifications in computing. Hint: those are the ones who shout the loudest, have the highest number of followers on Twitter, but have very little, if any, REAL code on Github or any other public repositories. So... when the masks start to fell off they usually bail out their jobs loudly and pointing fingers to preserve their public personas. I doubt this is not the case of Julie Ann.
"You can fool all the people some of the time, and some of the people all the time, but you cannot fool all the people all the time.", Abraham Lincoln
Long answer:
1. The learning curve is really steep. I mean, really really steep. There's a critical shortage of (good) books, video, and tutorials on the web. I guess ExtJS' learning resources should be 0.1% of jQuery's. The examples on Sencha site were still using the 3 version last time I checked;
2. If you need to customize ExtJS, or need something slightly more sophisticated than CRUD screen, then you are pretty much on your own. You'll spend a large amount of time trying to "fight" the framework and your chances you succeeding are very low;
3. It's expensive and its open source license has restrictions;
4. Sencha seems to hide and obscure the access to the learning resources so that you are pushed towards their paid support.
5. It's slow;
6. The error messages (when they show up!) are cryptic.
7. ExtJS was re-designed for version 4, but some things like the Model objects are cumbersome and suffer many usage limitations;
8. It will never be adopted as a general purpose solution on Internet facing webapps for the reasons exposed above;
Sorry, boys, but this paper looks like the result of a ill performed research job, done in a hurry of getting published.
If a company enter the what-is-the-hottest-language-of-the-week game it can easily drag itself in a downward spiral of death. Just because it boils down to taste! And it leaves a lot of hurted feelings around the way. Language is a lot about maintenance 10 years down the road.
Scala and Clojure each have significant design flaws, in my opinion, and neither would have been a significantly better choice.
Couldn't agree more! Be it a startup or a mega-corp, VPs should make their minds upfront and stay on their path until something amazingly better comes down the road. C'mon, if Google had chosen Scala, for example, they could have produced clean, concise code, FP-oriented software at the price of sluggish compilation times (many wasted minutes), lots and lots and lots of generated bytecodes, and binary incompatibility (ouch!). Jump into the trendy language badwagon and you find yourself nowhere pretty soon. I know of at least two prominent startups in Bay Area who are switching of Scala and adopting the old-fashioned Java, for many reasons, but fondness of OO or lack of vision are not among them. And a third startup is stealthily switching to Clojure. On the other hand, you have C/C++.
Only an idiot can assume that F1/Megastore is a drop-in replacement to MySQL (or Cassandra, jbellis!), but those guys invented BigTable, and battle tested it, long before writing the papers so they know where their priorities lie nowadays. On the other hand, I am highly curious about Spanner, the successor of BigTable, that powers F1.
I also agree that Java will be dead by 2014, but not as COBOL. It will be dead as C language is dead. Java is the C of the XXI century.
Damien Katz is just assuming the above reality and restarting from scratch . He's always stated that he was investing a lot of time, and sacrificing many things, so that he could support his family AND work on something relevant. Nevertheless, I dislike this strategy of abandoning a project by "donating" it to the open source community. Just call it quits, for God's sake!
1. Holds a BS/MSc/PhD from a famous US university (Stanford, Yale, Berkeley, etc) or a PhD in a known university.
2. Has publications or is a well renowned CS researcher/professor/veteran (including famous progr. lang. gurus)
3. Is/was the committer of a famous open source software
4. Has invented algorithms or data structures or programming language
5. Has worked on a major company like Microsoft, Oracle, or Intel;
6. Has been the finalist of programming competitions like ACM, TopCoder, etc.
I deal with passionate Oracle RDBMS users on a daily basis and (very good) technologies as BerkeleyDB and Coherence are nothing but esoteric toys they will hardly use anytime soon. So will be this NoSQL database that will probably be given away as open source.
Disclaimer: in spite of thinking that Akka is a very cool framework, I think it can quickly become something like Spring, that is, a humongous framework that tries to solve everybody's problems.
On the other hand, Scala is good for data crunching and mutable/immutable data processing. And you'd have a hard time dealing with mutable data on Erlang. As they are building a highly scalable data analytics system, it makes a lot of sense to couple the two languages. But I guess Akka is good enough to the other 98% of the use cases you may ever find. ;)
Oddly enough, BigTable's terminology seems fits more naturally in the classic concepts than Cassandra's. Maybe it's the result of Dynamo's design choices (DHT, etc) that got into the mix or new concepts like SuperColumn.
Keyspace: a hash table that holds your application data. Okay, the table is distributed among nodes (i.e.,a DHT), but it's still a hash table;
Row: an entry in the above hash table where each value is composed by a collection of "column-families".
Column Family: a key-value table (I avoid to call it a hash table because I don't remember if it's implemented as such). A better name for this thing would be 'Attribute Set'.
Column: it's a key-value pair (with timestamp). Thinking about it as a column just blurs the concept. Better name: 'Attribute'.
Note: it's possible to have a different set of attributes on a per-row basis (for the same Column Family), so this concept of 'column' breaks quite easily.
Super-column: key-value pair where the value is yet another key-value table! Better(?) name: 'Super-Attribute'.
Then Cassandra data model is in fact a nested set of key-value tables while dynamo's model is flat (just one level hash table). Oh! Last but not least, it's not a column-store. It's on-disk storage is row-oriented.
1) Stonebraker is an industry troll that likes to shamelessly advertise his current products while pointing 'problems' with the state of the art. And he usually emits clueless opinions about subjects he doesn't deal with.
2) In spite of Stonebraker, voltdb engineers are doing a serious job, and the product has its value;
3) It's virtually impossible (and high risky) to change the infrastructure of any company the size of Facebook/Google. As any software engineer research shows, it'll take years and lots of money to change a large code base and deploy other data management system. Of course, Facebook is using HBase now for new products, but the current MySQL based systems should account for millions of lines of code. It's worth to spend time developing new products or refactoring old code that is working?
4) Thousands of MySQL shards is a hell on earth, for sure. We should praise Facebook engineers for being able to manage it efficiently.