|
In a speech at London's Science Museum, the famed physicist says the Higgs boson discovery makes physics less interesting. He adds that we've only got 1,000 years left on Earth anyway. Oh, if only the Higgs were 140GeV, that would be interesting, wouldn't it?
|
|
|
|
|
oday, I’m very excited to launch Visual Studio 2013 and .NET 4.5.1. I am also thrilled to announce Visual Studio Online, a collection of developer services that runs on Windows Azure and extends the development experience in the cloud. Visual Studio 2013 and Visual Studio Online represent the beginning of a new era for Visual Studio, combining a powerful desktop IDE with rich developer services in the cloud. "To the moon, Alice, to the moon!"
|
|
|
|
|
Microsoft and cross-platform mobile-app development vendor Xamarin are tightening their technical and marketing ties under a new partnership deal. "The sum of the angles of that rectangle is too monstrous to contemplate!"
|
|
|
|
|
Oracle, which has already been working with HSA Foundation on projects, finally becomes a member. You had me at 'everybody' seeks Java performance boost
|
|
|
|
|
Fuel cells may be a strong alternative for powering data centers, Microsoft report concludes. It's better than putting a nuclear reactor into a Surface
|
|
|
|
|
American definition of a fuel cell: Gas tank.
|
|
|
|
|
why all the hate?
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering.-Wernher von Braun Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein
|
|
|
|
|
Don't get me wrong, I don't hate the US: It was rather a zynic outburst which made me using the oldest US cliché ever.
|
|
|
|
|
Few things in computing are as vital as the lowly hard drive. If your memory goes bad or your processor blows, it’s easy enough to switch out; when a hard drive gives up the ghost, your precious files expire along with it. Usually until 15 minutes before you create a backup
|
|
|
|
|
During. It's always during the effing backup.
Ugh.
|
|
|
|
|
The Computer History Museum has published the source code for the Apple II DOS. Last spring, CNET was first to report the existence of documents that led to the creation of the code. Go ahead: type it all in. It will be just like the old days.
|
|
|
|
|
Lack of large-screen phablet hurts Apple share, IDC says Start the "Apple is Doooooomed" bus!
|
|
|
|
|
Many useful additions make this an attractive release, but writing Windows Store apps remains clumsy work. "It's got a good beat and you can dance to it."
|
|
|
|
|
It's not really a new version (not based on the new features) - just a upgrade to 2012...
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is (V).
|
|
|
|
|
But the upgrades are, IMHO, valuable enough to justify the new version.
|
|
|
|
|
Over the past several years there has been an enormous amount of press over NoSQL, which is a way to store and retrieve data found in a less structured and less consistent form than relational databases. "If you hype something and it succeeds, you're a genius, it wasn't hype; if you hype it and it fails, then it's just a hype."
|
|
|
|
|
My only relationship (harhar) to NoSQL was when I was part of a conference call for an interesting website idea and the geeks on the call were wondering what kind of database to use. Someone (not me) said "let's use NoSQL!" and everyone (again, not me) said, "Yeah, Cool, Awesome!" without any thinking behind why we would do that.
And frankly, that experience is enough to keep me away from anything and everything in NoSQL land. I can handle unstructured structured data easily with a standard relational database, thank you very much, and quite frankly, the vast majority of data is structured, it's just that people are too lazy to work out the structure. In my HUMBLE opinion.
Marc
|
|
|
|
|
Yeah, there was a stretch there where the answer to every question seemed to be NoSQL. I think it falls happily into the "fast iteration, maybe we'll get an app out of it" mindset where "we don't need to think about the schema, we'll figure it out as we go along." Fine while you're fiddling, but I can't see how it really can compete long term with a relational db.
--------------
TTFN - Kent
|
|
|
|
|
<Rant>
Broadly speaking I am in favour of the NoSQL movement, but not in the way these guys think about it.
SQL is, strictly speaking, not a relational language and, in spite of their naming, most modern DBMS are not truly relational. Codd, who invented Relational DB's, defined 12 rules (0 to 12) that are requirements for a DB to be called relational. Codd's 12 Rules[^].
Unfortunately, marketing won and we got left with the results of Oracle rushing to market and inflicting SQL on us. Many of the results still plague us today. One example of SQL's not-relational nature is the support for duplicate rows in a relation (that includes result sets as well as tables). There is no meaningful way of distinguishing between those rows. It is often argued that these are needed for aggregate functions, but again that is a deficiency of the design of aggregation in SQL.
Christopher Date et al., in 1995, proposed The Third Manifesto[^]. This uses one of Codd's ideas Domains (for example, a measurement in inches has a different domain to a quanity of parts, and it is an error to compare the two) to produce a model of DB's that totally avoids the Object/Relational Impedance problem. Sadly, there are precious few implementations of this.
There are numerous other issues, but this is probably the earliest example of Oracle ruining a promising technology. It is a shame more people aren't aware of this.
Its just a shame to me that all the NoSQL movement has done is move to models of DB that throw away most of the benefits of the Relational Model, rather than correct the deficiencies of the current implementations of it.
</Rant>
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Rob Grainger wrote: SQL is, strictly speaking, not a relational language
Yeah, I've commented to people when I teach them about databases that SQL is neither Structured, nor just Query, and definitely not a Language.
Rob Grainger wrote: One example of SQL's not-relational nature is the support for duplicate rows in a relation
Isn't that something that a unique constraint could handle? I've definitely been bitten by duplicate rows when I haven't used constraints properly, and it sure is a PITA to delete all but one. At least Oracle had a Row ID, which SQL Server was lacking a similar concept many years ago. But perhaps I'm missing what you mean here.
Rob Grainger wrote: for example, a measurement in inches has a different domain to a quanity of parts, and it is an error to compare the two
Exactly! To do some of the automation I like to do, I end up coding a "metaschema" that allows me to provide, among other things, a much richer type definition for columns and tables.
Great post, BTW! Not a rant at all, IMO.
Marc
|
|
|
|
|
"Isn't that something that a unique constraint could handle?"
That's certainly true, but in the Relational Model, duplicate rows are expressly forbidden - even in queries. Row IDs are really a workaround, rather than a solution to the issue, and also violate the constraint that their should be no ordering in base relations (tables).
This hit me this week at work, where a (pre-existing) query was actually returning two rows rather than one and effectively selecting which one actually gets returned by some logic I was unaware of. This was then updated in code, leading directly to data inconsistencies. Had the original developer used UNIQUE, the result would not have been updateable and the problem could not occur.
Another key feature of domains is also worth considering. Each PK in the database is a unique domain. Joins can only be performed based on data from a common domain - this is (rightly) much more restrictive than the joins as implemented in mainstream DBMS. Again, I have seen this error occur in practice (although only once) with disastrous consequences.
Further, in V2 of the Relation Model (which has more rules and features), PK domains are database-wide: multiple tables may draw PK values from the same domain - but each PK value is still a unique identifier, that may be a PK value in more than one table. This feature could really help with object-relational mapping, so a table representing a subclass can share a PK with the table representing the base class without the need for special work to maintain consistency between the two. (It brings many other benefits too).
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Rob Grainger wrote: Each PK in the database is a unique domain. Joins can only be performed based on data from a common domain
Oi, that's brilliant. I think I'll hijack that idea.
Marc
|
|
|
|
|
With so many tools in every developer’s chain, it's difficult to tell which ones are actually improving overall product quality and predictability. This graph shows the effects various tools have on predictability, and that version control and IDEs are still the kings of developer tools. Two quarts of French Roast, and a #18 needle
|
|
|
|
|
I find it more than a little odd that code quality is at 56% when it's not monitored, and only goes up 7 percentage points, to 63%, when "Fix all". A 7% increase for what is probably a very costly and time consuming process seems rather ineffective. Gee, could that be an indicator of the "quality" of Java, or the metrics used to determine code quality?
What I glean from this is, even when "fixed all", the code quality of Java code still sucks. Hmmm...
Marc
|
|
|
|
|
I think the main flaw in the article occured in the pre-keyboard stage. Java is no worse than, and no better, other languages for having problems in quality. There are many ways to improve quality, none are perfect and all are applicable.
speramus in juniperus
|
|
|
|
|