|
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
|
|
|
|
|
Nagy Vilmos wrote: Java is no worse than, and no better, other languages for having problems in quality.
I do actually think that a language and quality are at least somewhat interconnected, and I would imagine that Java actually has a higher quality rating than some certain other languages. 
Nagy Vilmos wrote: There are many ways to improve quality, none are perfect and all are applicable.
It would be interesting to see if there is something intrinsic about a language that can degrade (or improve) quality. The "quality" of code I see in VB, for example, is atrocious, but is that the language itself? I can say the same for Ruby, but I also know that I can write high quality Ruby code, so it seems more of a discipline and skill issue.
Marc
|
|
|
|
|
More productive in compare to who?
Maybe to the Java developer of the last year?
I can't see how these numbers and graphs says anything about productivity. It talks about habits and try to show the impact of that habits on code quality...
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is (V).
|
|
|
|
|
I interpreted it as "What makes some Java developers more productive than others", but it could have been phrased better.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Our survey of more than 3,000 developers and managers shows that after several years of being flat, salaries are on the rise once again "I got a little change in my pocket going ching-a-ling-a-ling"
|
|
|
|
|
Here is another salary review for the O+G Industry 2013, it shows how the various sectors are fluctuating and also which regions are in demand. As you would imagine there is a huge service industry sitting behind this of which IT is a part of it, so it has a direct bearing on a lot of areas.
http://hays.clikpages.co.uk/Oil_and_Gas_Salary_Guide_2013/[^]
|
|
|
|
|
Can't wait for the death of oil, long live green energy
<a href="http://www.software-kinetics.co.uk"><span style="font-family:Arial, Helvetica, sans-serif; color:#006C97;">Software Kinetics</span></a> - <span style="font-family:Arial, Helvetica, sans-serif; color:#333;">Dependable Software</span>
<a href="http://blog.software-kinetics.co.uk/"><span style="font-weight:bold;font-family:Arial, Helvetica, sans-serif; color:#333;">news</span></a>
|
|
|
|
|
As long as it sees me through to my retirement I'll be happy (maybe longer, depends what my kids end up wanting to do).
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
