Uhm, yeah. Gotta tell that to my friends at work. Their VMWare-virtual hosts aren't constantly rebooting themselves and go down, crash in kernel, drift in clock etc. It just seems like it.
Also, the way they manage to get some 15 poorly performing servers out of hardware and software investments close to 50k Euro must be brilliant. We only get decent performing servers for some 1.5-2k Euro/Server (WITH full redundancy for the services that requires it, including separate disk-arrays).
Sorry, but I don't buy VMWare (or any other host-level virtualisation for that matter) as a solution to everything as many people tend to do nowadays. Host virtualisation is good for quickly jamming out test-environments for software integration and testing new and different software stacks and OS:ed.Possibly also virtual hosting for customers that needs to run their own OS. For other purposes the service/server differentiation in the standard OS/Process - model tend to work out pretty well. If you need to get fancy, OS-virtualisation may be an option.
Considering how different the prices of pharmaceuticals are today in different countries, manufacturing-costs are hardly a part of the picture.
Which pretty much relates to the top-most parent in thread. Items such as knowledge, which is quick and almost free to copy, should not have property attached to them. If you ask me, they should be developed in the public domain, with public funding, public participation and public benefits.
As an example, movies. Producing movies are getting cheaper and cheaper to produce, and the entertainment factor is more and more determined by the creativity of the creators, rather than the investments in heavy studios etc. The cost that is difficult to remove is the working time by the authors, but that is also relatively easy to predict.
I were on a job-interview a couple of weeks ago, where the discussion went into general feelings, beliefs and ideas regarding IP, patents and production of digital content. The interviewer, (Hans Höök, for the sake of attribution) suggested a model based on pre-pay to create movies, but it would apply to other IP-based products as well.
The idea is to have a team with a movie concept sit down together, create the scetches, concept art, scripts, trailer or a pilot, whatever needed to convince a community of people that this movie will actually be worth watching. This material is then published for public viewing, with a virtual "cookie jar" where viewers can donate some cash if they want to see the final work being produced. If the work-cost of the movie is reached, the movie will get produced, if not, an important key is to have a payment mediator (paypal?) that ensures those who donated gets their money back.
Similarily, this concept would extend to other areas of IP as well, one of the ones in place today is the concept of bounties, which is used by a few projects today to get contribution.
As usual, Wikipedia, while not being absolute truth, or even a credible source, sums things up better than I can myself.
Network effects are a source of, but distinct from, lock-in. Lock-in can result from network effects, and network effects generate increasing returns that are associated with lock-in. However, the presence of a network effect does not guarantee that lock-in will result. For example, if the network is open there is no issue of lock-in. I certainly agree that there's plenty of business value in using proprietary communications rather than resorting to inferior methods of communication.
However, proprietary communications protocols are text-book examples of how network-effect easily creates barriers to technological changes, which is a mild kind of lock-in. (Not the worst form, but certainly bad.)
Anyone around before reverse-engineered multi-protocol IM-clients became commonplace, or that requires MSN connectivity only because that happens to be what some friends are using, knows exactly what it's like in practice.
Actually, depending on the use and exactly HOW you target requests, you can gain performance.
If you're careful about how you send your requests, you can really improve the cache-performance of the slave servers. Say each server get requests that depends on roughly the same resources and that'll improve performance a LOT.
The thing is, you're probably already doing DBC in some form. If you document your code (and I'm sure you are ?;) You are already giving out contracts.
Contract-based programming is simply about formalising those contracts to a form where it can be used for documentation, testing AND code analysis, all at once.
If that's not appealing, well then I guess DBC really isn't your thing.:)
Btw, can you point me to an example where DBC gives you more code compared to a test-driven-design?
Well, DBC is about just that, designing by contract, making code give promises on how it works, and be explicit about it.
Just as you can be object-oriented in many objects without object-orientation-mechanisms built-in, you can DBC in almost any language. (Implicitly, you do it whenever you write documentation.)
DBC however encourages knitting the contract directly into the code, and making it enforceable in a variety of ways, where testing is often perceieved as the more useful way.
Also, DBC can be implemented slightly differently, where some implementations are strictly test-focused, and others more aimed at letting the compiler mathematically enforcing the validity of your code.
So yes, DBC is (partially) about testing, but only as a method of verifying your contracts.:)
Mocks are basically the fundamental difference between DBC and Unit-testing (As a methodology, not as one of the test-methods in DBC.)
Unit-testing as a methodology tries to impose a kind of modularity and isolation in your code that truth be told is not always sensible.
It's not uncommon that a perfectly good design contains a few units very tightly coupled together to the point where it's more useful to test them together as they are used, rather than painfully trying to drive them apart to the point where they are tested under conditions that, strictly speaking, is not really sensible for their real use and thus should not be part of their respective contracts.
The main viable reason I can see for mocking away parts of your code are performance-reasons, and components that may require interaction to users or external components that can't be integrated into the test. (I.e. a business-system where getting a test-setup for development is not an option.)
Oops, re-read your post and realised we're probably already on the same page.:)
Except with good DBC tools, you wouldn't need to drive your unit-tests much yourself, though. The interface specification allows fuzz-testing (http://en.wikipedia.org/wiki/Fuzz_testing) + explicit corner-case-testing to be a great automated way to drive your code.
I really think you should spend some time looking at the reasoning behind DBC. Reading your comments here makes me suspect that you're already, like me, thinking much in the lines of DBC when you're "unit-testing".
It seems as you, like me, acknowledge that any real-world application tends to be by far too complex to realistically except to be able to fully use unit-tests of all units completely isolated. Instead, you and I (different from the usual definition of a unit in unit-testing) consider a unit to be a hierarchial element of the code, ranging from the system as a whole, including all processes, threads, protocols etc, down to the really simple method such as addTwoInts(a,b).
DBC and unit-tests are closely related, but they are a big fundamental difference.
* Unit-testing as a methodology tries to impose a certain kind of modularity and isolation on your code. I.e. mocking away everything else than the fundamental unit you're working on requires mostly all code to be implemented through interfaces in a typed language.
* DBC does not really impose any such requirements on your code (other than to design sensibly and actually define contracts). It relates much more on how your code is used in YOUR application, and defining how it may be used in someone elses. In DBC you also spend some time writing interface-specifications, but here you don't do it for the purpose of mocking the object later, you do it as a part of defining the interface of the unit which can later serve both for automatically driven testing, input validation, and API-documentation.
An example: Two fundamental units A and B, where B depends on A. Unit-testing suggests mocking away A for testing B, while DBC don't care, and considers testing of A to be a part of the testing of B.
In practice, the big fundamental difference between unit-testing and DBC is that DBC does not make a big difference between unit-testing and all other testing, similarily to what I'm reading between the lines in your posts.
In DBC, you may write a few unit-tests for them both if there's anything in particular you want to constantly verify when building, but the focus of DBC is performing the tests directly in YOUR application, with higly granular verification to easily detect and track down problems.
Am I making any sense? If not, please go ahead and read http://www.digitalmars.com/d/2.0/dbc.html. It's a bit shorter, and maybe more clear. (D-specific but it gives some idea of the concept.)
Actually, DBC is not at all about sprinkling asserts into your code. DBC is about modelling your interfaces between code components very carefully.
The asserts only tests that your code actually fulfills the contract (while themselves being contracts). Also, ideally your assertions should not be sprinkled in the code itself, but separate enter-exit-conditions and class invariants held separate from your implementing code. (This, of course is best shown in a language with DBC-built-in, or a templating-based overlay on other languages.)
So, don't confuse assertions with DBC any more than you confuse classes with object-oriented programming. Classes is just one method of implementing OOP, just as assertions is just one method of implemeting DBC.
The biggest strength of DBC according to me, is the enter-exit-conditions of methods. They are highly reusable and is valid both for the method they are attached to, and also any subclassed method, while class-invariants may be tied to the implementation more than the actual contract.
The problems with unit test as someone already pointed out, is that writing small tests helps you verify the really simple things is relatively quick and easy but, those mistakes are easy to detect and find anyways, even a decent compiler/lint-tool will find many of them for you.
Most of the really tricky problems comes in the interfacing between units and no unit tests will help you here.
Design-by-contract, on the other hand, can.
First of all it requires you to give really clear formal declaration on each component and how it may be used. (A contract) This contract can be used to automate testing of all the exotic, but allowed, corner-cases your implementation may have missed.
The contract implemented by classes and function will furthermore function as a REALLY clear documentation, spelling out exactly what the allowed input and expected output is.
Finally, in a design-by-contract-enabled language, you can choose to turn on debugging at run-time, and enable all kinds of tests, including input/output validation, class invariants and other really handy tests that allows you to test AND debug your entire system at once, but still at a highly granular level.
Design-by-contract will in no way prevent you, or discourage you, from writing test-code (in fact, it encourages it), but it can help you spend your time writing those tests more sensibly, and drive your code in much more life-like scenarios.
All in much less time spent, and much more return than the traditional ways of unit-testing.
"my dualcore laptop really has no problem with that" Moore's law says (well, indirectly at least) that machines from 2007 should be roughly 256 times as powerful as machines from 1995.
Somehow, the actual performance difference (starting the computer, starting a web-browser, editing text etc.) in running Win95 on hardware from it's time, compared to running Vista on todays hardware, seems to be nowhere near a 256-times improvement.
I can only conclude that while the hardware-industry have improved itself again and again, the software industry have ate almost all of those improvements, instead of giving it to the users.
I'm a bit interested in this. Have a more thorough explanation on how, or a link describing such setup?
Is it possible/viable with "curious" software where the engineer thought with his ass and typed with his foot? (A serious question, I happen to admin a few such systems)
Which is only one of the countless reasons why NAT must die. By coincidence, IPv6 doesn't encourage NAT, and IPSEC is a lot firmer integrated there.
(Also, don't EVER trust your NAT-gw to be a firewall, especially not if it's UPnP-enabled in which case it's actually very likely to be the spy itself.)
The problem is that a very deep passion (obsession?) about something tend to lead to loss of other skills (humour, social skills, or in my case, loss of the entire right half of my brain).
Exactly WHAT the passion is all about is in my experience not very important. Geeks just happen to be a popular example, but some other examples are:
- Business-people not knowing when to shut up about their latest deals.
- People obsessed over their own (and usually, others) appearance forgetting all about verbal communication or keeping up with news making it impossible to keep up smalltalk.
- Extremely outgoing social people, making it a point to know a lot of people. They can be completely useless as friends or boyfriend-girlfriend material since they never learnt how to commit to a single relationship.
So in essence, I think the problems with being a geek is that you almost per definition are close to an obsession, which automatically will make you care less about other skills and aspects of your personality. So I would say that to some extent yes, being a geek has a good chance of making you less attractive, but it's completely your choice how far you want to go. It's no reason to give up a social life but, as with most things, it's a matter of priorities.
I second that. D has probably the best potential of all right now. The one thing they HAVE missed, though, is good fundamentals for parallelism. Threads just don't cut it, and even threads aren't really built into the language for D.
First, the 48 errors/1000LOC is pretty quick to find and catch using regular debugging techniques as well. It's the remaining two that are difficult to find either using formal verification, or debugging. In real-world, stuff like good compilers/lint-tools and som common sense in how you design your API:s will get you a long way.
Second, the usual problem in _most_ software engineering projects is not really bug fixing. It's that requirements usually change pretty drastically during the development process which is quite expensive but hard to avoid (you don't really know until you've tried it). Neither unit-testing nor formal verification is a big help here, since when basic requirements change, so does the entire function of the program, and all unit-code and verification-code needs changing.
Finally, the main problem in any human activity is the risk of human error. I've seen people using test-driven development writing horrible tests that just happen to work for the implementation they planned, but are fundamentally flawed and end up in a broken application anyways. On the flip-side, I've seen very careful skilled developers writing completely functional, relatively complex code completely without unit-testing or verification, and nomatter how much I tried and wanted to prove them wrong, I just could not break the darn thing.
In the end, it comes down to the skill and aptitude of the developer, combined with the assistive tools that can save him from the more common mistakes. (Compiler-checks, lintian, automated security-code-scanners...) What unit-testing AND formal specification models both bring is the N-degree-programming, that is, you must make TWO matching mistakes for an error to go undetected, which adds some extra safety. Of the two, I choose formal verification, since it enables automated tools to do a better job generating tests than I can, and I get an API documentation for free.:)
It's nice to see some new languages like D coming up with subsets of the verification tools built in. In D, you also get the option to run debug-mode of your real code in real environment, with verification turned on, showing you where things go wrong. Kindof like the strict mother of assert().
In a more primitive form, it's the Sun/IETF-driven XDR format http://www.faqs.org/rfcs/rfc4506.html. Many other binary protocol uses and respects parts of the XDR-format, even if not completely. XDR however is in no way general-purpose, as it does not include enough information about the implementing formats in order to make extensible simple formats based on them.
Then there's EBML - Extensible Binary Metadata. It's a bit underspecified, does leave room for extensible protocols, semantically resemble XML in many ways, very fast to implement, but do have some shortcomings in terms of flexibility, and neither does include sufficient metadata to do intelligent things by just watching a message/document. Also it can never implement some kind of generic editor.
Then there's my own little dormant project, runestone. http://runestone.sourceforge.net/ It kindof combines the greatest strengths of XML, with the strengths of binary languages, and then some. It implements extensibility on two levels, both on the same ad-hoc decentralized level as XML, but the format itself is from start designed to be modular and extensible (although in a more synchronized central-control fashion). It allows for features like semi-transparent encryption, compression, checksumming and cryptographic authentication. It's pretty much written with XMPP and SVG in mind, and features things like arrays of uniform data-types, (Excellent for a graphics-format like SVG) prefix-length encoding of all datatypes with variable length, allowing an XMPP-server to "fast-zap" over things in the communication it doesn't need to know. (Like the payload of messages). But it also would enhance protocols like HTML quite a bit by, I.E. faster parsing, embedded inline binaries (like images without an auxiliary http fetch), and options to authenticate parts of a transferred data-stream.
Most important of all, the Runestone format would allow for generic content editor, much like a text-editor is pretty generic for many formats today, but in a way that does not mix information with visual representation. (I.E. your editor not only could, but MUST choose indentation and other styling according to it's own or your preferences). The format simply won't contain them. I think this feature, above all, is critical for a general-purpose binary format.
Other than that, a general-purpose binary format could allow for some very neat indexing opportunities whereas indexers doesn't really need to understand the semantics of a specific document-type, but only the syntax which itself when using the index some of the semantic may be guessed from the syntax. I.E. looking for everything where "author=John Doe", indifferently of document type, based on any document that somewhere in it has an attribute with the value John Doe.
Also, things like version-control of more arbitrary data would be possible, through tree-deltas. Could improve things like ODF a little.
I'm not saying Runestone is the way to go. It's not even, contradictionary to it's name, a format set in stone yet anyways. But I DO think some of the possible characteristics of a binary generic language somewhere along that spirit could prove _very_ useful.
I agree with you on the problems of XML, but not on the solution.
The problem with XML are also inherent in JSON and every other text-based format; it builds it information-model on a thin but heavy and slippering layer of text. If you've further tried using authenticated e-mails through S/MIME or PGP, you probably seen yet a few.
Anyone using a non-ASCII-language have seen one of the issues of all current text-based formats first-hand; encoding. Text-based isn't actually a guarantee for anything, since it's not a single specification, but rather a dim view of something that is probably ASCII-compatible. (But not necessarily.)
One of the most obvious examples of this is SVG and SOAP. Both in SVG and SOAP, there is a frequent need to transfer some non-text data such as embedded bitmaps, integers, floats and possibly other elements. Done over XML (or any text-based format) this immediately becomes a very big task passing through layers of text-encoding, lexical analysis, semantical analysis, DOM-construction (not necessary with a SAX-parser but that's a it's own story), the assumption that integers will be decimal written in small-endian, and finally back to the data-structure that it actually was at the beginning. Then you're ready to actually start with the real interpretation of the data.
Alternatively, say it's an array of integers, say "here comes 320 32-bit unsigned integers" and just send them (in network-endianess). A LOT less error-prone, a LOT faster, and a LOT easier on both ends. Alternatively, say "here comes a 4mbyte bitstream" and just transfer your image. In that way, the parser may even skip the 4mbytes, since it's not really looking for the image right now. Finally, but possibly most important, if you want to transfer some text, you say "here comes 48bytes of UTF-8 text" and then send it. This way, whomever reads this will KNOW how the text is encoded, and be able to do something sensible with it, as opposed to mere guessing.
As an example of the charset-issues, just consider that in a standard XHTML-document, there will be 3 possible places to tell the client what encoding to use, and no guarantee any of them will match. First, the HTTP-header, secondly in the XML-declaration and finally in the Meta-tags. To show the problem, look at the first example of http://www.webreference.com/authoring/xhtml/coding/, where even a page trying to explain it gives of an incorrect example without mentioning the error. JSON does it slightly better, determining that all content should be encoded in a Unicode-encoding avoiding some of the issues, but instead facing the issues of Unicode http://en.wikipedia.org/wiki/Unicode#Issues.
So, while I agree on XML being way to heavy-wheight, I don't see JSON to be the solution, still being built on text.
Well, mov isn't available on Windows without additional software the last time I tried it. Neither on Linux. I suspect it's still the case with MPEG-4 as well, not available on Windows without additional software, and on Linux not legally available at all in many countries.
And I wouldn't say this being a OS-matter either, or at least shouldn't be. Since no browser supports HTML5 at all yet, what's available on the platforms TODAY now are relatively uninteresting, compared to the ease with which the formats CAN be implemented in order to comply with HTML5. Most of the formats are covered by patents and license fees, which makes them, even if not technically hard, practically close to impossible to implement in many platforms, especially free software.
Also, a standard such as the web should not depend on licensed technology. (At least not IMHO) This is where the Xiph-patents have an edge. They are, at least supposedly, not encumbered by patented technology and thus free for use by anyone. They've also got a freely portable implementation, which can easily be incorporated into browsers. There may be other formats that fits by the same arguments, and if so they should also be considered.
Regarding streaming of different codecs, resolutions and bitrates, this is handled by RTSP and RTP, and IMHO should stay there. (No point in having to download parts of the content you don't want.) I'm not sure how you mean.MOV deals with this, as I can't find any references.
My basic standpoint: Since Audio/Video and streaming is becoming an essential part of the web, a list of recommended formats and codec are needed to ensure standards-based interoperability. An internet standard should not depend on licensed technology, and thus, Xiph codec are one logical candidate for recommendation. (And yes, I too would like to see a trial of the true Legal State of Xiph-codecs.)
Not necessary at all. The point of a standardized format is to allow content creators publish their content in a format they know most of the audience will be able to support.
In the case of images, you don't usually require the user to download "Photoshop Viewer Plugin" so you can embed.psd-files in your image-tags. In the same way, there should be one or a couple of standardized formats for video that can be assumed by the content creator to be supported by the browser.
If you then for some technical reason/preference require support for different formats, it's essential for the specification to allow extensions. I.E. allow special plugins to support FairPlay-DRM in order to sell movies on their sites.
But again, just like images, there should be "standard" content formats to fall back on for maximal compatibility.
Sorry, but I think this belief is flawed. Many payloads for different types of automated attacks such as trojans and worms today are smart enough to be dynamic and handle many different environments. I.e. they detect what mailer you're using and use it to send spread it's word, to add authenticity. It detects what I'm, what addressbook and what browser you're using, to skim for passwords and similar to mail back to it's master etc.
I think worms, soon if not already will contain detection mechanisms to exploit a variety of hypervisors. If nothing else, it will most likely be able to crunch some numbers (say, it's part of the storm botnet) and dehash your admin p/w which for most systems will be the same in all servers.
Slashdot Mirror
Uhm, yeah. Gotta tell that to my friends at work. Their VMWare-virtual hosts aren't constantly rebooting themselves and go down, crash in kernel, drift in clock etc. It just seems like it.
Also, the way they manage to get some 15 poorly performing servers out of hardware and software investments close to 50k Euro must be brilliant. We only get decent performing servers for some 1.5-2k Euro/Server (WITH full redundancy for the services that requires it, including separate disk-arrays).
Sorry, but I don't buy VMWare (or any other host-level virtualisation for that matter) as a solution to everything as many people tend to do nowadays. Host virtualisation is good for quickly jamming out test-environments for software integration and testing new and different software stacks and OS:ed.Possibly also virtual hosting for customers that needs to run their own OS. For other purposes the service/server differentiation in the standard OS/Process - model tend to work out pretty well. If you need to get fancy, OS-virtualisation may be an option.
Considering how different the prices of pharmaceuticals are today in different countries, manufacturing-costs are hardly a part of the picture.
Which pretty much relates to the top-most parent in thread. Items such as knowledge, which is quick and almost free to copy, should not have property attached to them. If you ask me, they should be developed in the public domain, with public funding, public participation and public benefits.
As an example, movies. Producing movies are getting cheaper and cheaper to produce, and the entertainment factor is more and more determined by the creativity of the creators, rather than the investments in heavy studios etc. The cost that is difficult to remove is the working time by the authors, but that is also relatively easy to predict.
I were on a job-interview a couple of weeks ago, where the discussion went into general feelings, beliefs and ideas regarding IP, patents and production of digital content. The interviewer, (Hans Höök, for the sake of attribution) suggested a model based on pre-pay to create movies, but it would apply to other IP-based products as well.
The idea is to have a team with a movie concept sit down together, create the scetches, concept art, scripts, trailer or a pilot, whatever needed to convince a community of people that this movie will actually be worth watching. This material is then published for public viewing, with a virtual "cookie jar" where viewers can donate some cash if they want to see the final work being produced. If the work-cost of the movie is reached, the movie will get produced, if not, an important key is to have a payment mediator (paypal?) that ensures those who donated gets their money back.
Similarily, this concept would extend to other areas of IP as well, one of the ones in place today is the concept of bounties, which is used by a few projects today to get contribution.
However, proprietary communications protocols are text-book examples of how network-effect easily creates barriers to technological changes, which is a mild kind of lock-in. (Not the worst form, but certainly bad.)
Anyone around before reverse-engineered multi-protocol IM-clients became commonplace, or that requires MSN connectivity only because that happens to be what some friends are using, knows exactly what it's like in practice.
Ever heard of The Network Effect?
Actually, depending on the use and exactly HOW you target requests, you can gain performance.
If you're careful about how you send your requests, you can really improve the cache-performance of the slave servers. Say each server get requests that depends on roughly the same resources and that'll improve performance a LOT.
The thing is, you're probably already doing DBC in some form. If you document your code (and I'm sure you are ? ;) You are already giving out contracts.
:)
Contract-based programming is simply about formalising those contracts to a form where it can be used for documentation, testing AND code analysis, all at once.
If that's not appealing, well then I guess DBC really isn't your thing.
Btw, can you point me to an example where DBC gives you more code compared to a test-driven-design?
Well, DBC is about just that, designing by contract, making code give promises on how it works, and be explicit about it.
:)
Just as you can be object-oriented in many objects without object-orientation-mechanisms built-in, you can DBC in almost any language. (Implicitly, you do it whenever you write documentation.)
DBC however encourages knitting the contract directly into the code, and making it enforceable in a variety of ways, where testing is often perceieved as the more useful way.
Also, DBC can be implemented slightly differently, where some implementations are strictly test-focused, and others more aimed at letting the compiler mathematically enforcing the validity of your code.
So yes, DBC is (partially) about testing, but only as a method of verifying your contracts.
Mocks are basically the fundamental difference between DBC and Unit-testing (As a methodology, not as one of the test-methods in DBC.)
Unit-testing as a methodology tries to impose a kind of modularity and isolation in your code that truth be told is not always sensible.
It's not uncommon that a perfectly good design contains a few units very tightly coupled together to the point where it's more useful to test them together as they are used, rather than painfully trying to drive them apart to the point where they are tested under conditions that, strictly speaking, is not really sensible for their real use and thus should not be part of their respective contracts.
The main viable reason I can see for mocking away parts of your code are performance-reasons, and components that may require interaction to users or external components that can't be integrated into the test. (I.e. a business-system where getting a test-setup for development is not an option.)
Oops, re-read your post and realised we're probably already on the same page. :)
Except with good DBC tools, you wouldn't need to drive your unit-tests much yourself, though. The interface specification allows fuzz-testing (http://en.wikipedia.org/wiki/Fuzz_testing) + explicit corner-case-testing to be a great automated way to drive your code.
I really think you should spend some time looking at the reasoning behind DBC. Reading your comments here makes me suspect that you're already, like me, thinking much in the lines of DBC when you're "unit-testing".
It seems as you, like me, acknowledge that any real-world application tends to be by far too complex to realistically except to be able to fully use unit-tests of all units completely isolated. Instead, you and I (different from the usual definition of a unit in unit-testing) consider a unit to be a hierarchial element of the code, ranging from the system as a whole, including all processes, threads, protocols etc, down to the really simple method such as addTwoInts(a,b).
DBC and unit-tests are closely related, but they are a big fundamental difference.
* Unit-testing as a methodology tries to impose a certain kind of modularity and isolation on your code. I.e. mocking away everything else than the fundamental unit you're working on requires mostly all code to be implemented through interfaces in a typed language.
* DBC does not really impose any such requirements on your code (other than to design sensibly and actually define contracts). It relates much more on how your code is used in YOUR application, and defining how it may be used in someone elses. In DBC you also spend some time writing interface-specifications, but here you don't do it for the purpose of mocking the object later, you do it as a part of defining the interface of the unit which can later serve both for automatically driven testing, input validation, and API-documentation.
An example:
Two fundamental units A and B, where B depends on A. Unit-testing suggests mocking away A for testing B, while DBC don't care, and considers testing of A to be a part of the testing of B.
In practice, the big fundamental difference between unit-testing and DBC is that DBC does not make a big difference between unit-testing and all other testing, similarily to what I'm reading between the lines in your posts.
In DBC, you may write a few unit-tests for them both if there's anything in particular you want to constantly verify when building, but the focus of DBC is performing the tests directly in YOUR application, with higly granular verification to easily detect and track down problems.
Am I making any sense? If not, please go ahead and read http://www.digitalmars.com/d/2.0/dbc.html. It's a bit shorter, and maybe more clear. (D-specific but it gives some idea of the concept.)
Actually, DBC is not at all about sprinkling asserts into your code. DBC is about modelling your interfaces between code components very carefully.
The asserts only tests that your code actually fulfills the contract (while themselves being contracts). Also, ideally your assertions should not be sprinkled in the code itself, but separate enter-exit-conditions and class invariants held separate from your implementing code. (This, of course is best shown in a language with DBC-built-in, or a templating-based overlay on other languages.)
So, don't confuse assertions with DBC any more than you confuse classes with object-oriented programming. Classes is just one method of implementing OOP, just as assertions is just one method of implemeting DBC.
The biggest strength of DBC according to me, is the enter-exit-conditions of methods. They are highly reusable and is valid both for the method they are attached to, and also any subclassed method, while class-invariants may be tied to the implementation more than the actual contract.
Testing is not a waste of time. Writing unit-tests, is. A better use of that time could be learning about http://en.wikipedia.org/wiki/Design_by_contract, and possibly a language that implements it. (Dare I suggest http://en.wikipedia.org/wiki/D_(programming_language) ?)
The problems with unit test as someone already pointed out, is that writing small tests helps you verify the really simple things is relatively quick and easy but, those mistakes are easy to detect and find anyways, even a decent compiler/lint-tool will find many of them for you.
Most of the really tricky problems comes in the interfacing between units and no unit tests will help you here.
Design-by-contract, on the other hand, can.
First of all it requires you to give really clear formal declaration on each component and how it may be used. (A contract) This contract can be used to automate testing of all the exotic, but allowed, corner-cases your implementation may have missed.
The contract implemented by classes and function will furthermore function as a REALLY clear documentation, spelling out exactly what the allowed input and expected output is.
Finally, in a design-by-contract-enabled language, you can choose to turn on debugging at run-time, and enable all kinds of tests, including input/output validation, class invariants and other really handy tests that allows you to test AND debug your entire system at once, but still at a highly granular level.
Design-by-contract will in no way prevent you, or discourage you, from writing test-code (in fact, it encourages it), but it can help you spend your time writing those tests more sensibly, and drive your code in much more life-like scenarios.
All in much less time spent, and much more return than the traditional ways of unit-testing.
"my dualcore laptop really has no problem with that"
Moore's law says (well, indirectly at least) that machines from 2007 should be roughly 256 times as powerful as machines from 1995.
Somehow, the actual performance difference (starting the computer, starting a web-browser, editing text etc.) in running Win95 on hardware from it's time, compared to running Vista on todays hardware, seems to be nowhere near a 256-times improvement.
I can only conclude that while the hardware-industry have improved itself again and again, the software industry have ate almost all of those improvements, instead of giving it to the users.
I'm a bit interested in this. Have a more thorough explanation on how, or a link describing such setup?
Is it possible/viable with "curious" software where the engineer thought with his ass and typed with his foot? (A serious question, I happen to admin a few such systems)
Which is only one of the countless reasons why NAT must die. By coincidence, IPv6 doesn't encourage NAT, and IPSEC is a lot firmer integrated there. (Also, don't EVER trust your NAT-gw to be a firewall, especially not if it's UPnP-enabled in which case it's actually very likely to be the spy itself.)
The problem is that a very deep passion (obsession?) about something tend to lead to loss of other skills (humour, social skills, or in my case, loss of the entire right half of my brain).
Exactly WHAT the passion is all about is in my experience not very important. Geeks just happen to be a popular example, but some other examples are:
- Business-people not knowing when to shut up about their latest deals.
- People obsessed over their own (and usually, others) appearance forgetting all about verbal communication or keeping up with news making it impossible to keep up smalltalk.
- Extremely outgoing social people, making it a point to know a lot of people. They can be completely useless as friends or boyfriend-girlfriend material since they never learnt how to commit to a single relationship.
So in essence, I think the problems with being a geek is that you almost per definition are close to an obsession, which automatically will make you care less about other skills and aspects of your personality. So I would say that to some extent yes, being a geek has a good chance of making you less attractive, but it's completely your choice how far you want to go. It's no reason to give up a social life but, as with most things, it's a matter of priorities.
I second that. D has probably the best potential of all right now. The one thing they HAVE missed, though, is good fundamentals for parallelism. Threads just don't cut it, and even threads aren't really built into the language for D.
Some reflections;
:)
First, the 48 errors/1000LOC is pretty quick to find and catch using regular debugging techniques as well. It's the remaining two that are difficult to find either using formal verification, or debugging. In real-world, stuff like good compilers/lint-tools and som common sense in how you design your API:s will get you a long way.
Second, the usual problem in _most_ software engineering projects is not really bug fixing. It's that requirements usually change pretty drastically during the development process which is quite expensive but hard to avoid (you don't really know until you've tried it). Neither unit-testing nor formal verification is a big help here, since when basic requirements change, so does the entire function of the program, and all unit-code and verification-code needs changing.
Finally, the main problem in any human activity is the risk of human error. I've seen people using test-driven development writing horrible tests that just happen to work for the implementation they planned, but are fundamentally flawed and end up in a broken application anyways. On the flip-side, I've seen very careful skilled developers writing completely functional, relatively complex code completely without unit-testing or verification, and nomatter how much I tried and wanted to prove them wrong, I just could not break the darn thing.
In the end, it comes down to the skill and aptitude of the developer, combined with the assistive tools that can save him from the more common mistakes. (Compiler-checks, lintian, automated security-code-scanners...) What unit-testing AND formal specification models both bring is the N-degree-programming, that is, you must make TWO matching mistakes for an error to go undetected, which adds some extra safety. Of the two, I choose formal verification, since it enables automated tools to do a better job generating tests than I can, and I get an API documentation for free.
It's nice to see some new languages like D coming up with subsets of the verification tools built in. In D, you also get the option to run debug-mode of your real code in real environment, with verification turned on, showing you where things go wrong. Kindof like the strict mother of assert().
Well,
In a more primitive form, it's the Sun/IETF-driven XDR format http://www.faqs.org/rfcs/rfc4506.html. Many other binary protocol uses and respects parts of the XDR-format, even if not completely. XDR however is in no way general-purpose, as it does not include enough information about the implementing formats in order to make extensible simple formats based on them.
Then there's EBML - Extensible Binary Metadata. It's a bit underspecified, does leave room for extensible protocols, semantically resemble XML in many ways, very fast to implement, but do have some shortcomings in terms of flexibility, and neither does include sufficient metadata to do intelligent things by just watching a message/document. Also it can never implement some kind of generic editor.
Then there's my own little dormant project, runestone. http://runestone.sourceforge.net/ It kindof combines the greatest strengths of XML, with the strengths of binary languages, and then some. It implements extensibility on two levels, both on the same ad-hoc decentralized level as XML, but the format itself is from start designed to be modular and extensible (although in a more synchronized central-control fashion). It allows for features like semi-transparent encryption, compression, checksumming and cryptographic authentication. It's pretty much written with XMPP and SVG in mind, and features things like arrays of uniform data-types, (Excellent for a graphics-format like SVG) prefix-length encoding of all datatypes with variable length, allowing an XMPP-server to "fast-zap" over things in the communication it doesn't need to know. (Like the payload of messages). But it also would enhance protocols like HTML quite a bit by, I.E. faster parsing, embedded inline binaries (like images without an auxiliary http fetch), and options to authenticate parts of a transferred data-stream.
Most important of all, the Runestone format would allow for generic content editor, much like a text-editor is pretty generic for many formats today, but in a way that does not mix information with visual representation. (I.E. your editor not only could, but MUST choose indentation and other styling according to it's own or your preferences). The format simply won't contain them. I think this feature, above all, is critical for a general-purpose binary format.
Other than that, a general-purpose binary format could allow for some very neat indexing opportunities whereas indexers doesn't really need to understand the semantics of a specific document-type, but only the syntax which itself when using the index some of the semantic may be guessed from the syntax. I.E. looking for everything where "author=John Doe", indifferently of document type, based on any document that somewhere in it has an attribute with the value John Doe.
Also, things like version-control of more arbitrary data would be possible, through tree-deltas. Could improve things like ODF a little.
I'm not saying Runestone is the way to go. It's not even, contradictionary to it's name, a format set in stone yet anyways. But I DO think some of the possible characteristics of a binary generic language somewhere along that spirit could prove _very_ useful.
I agree with you on the problems of XML, but not on the solution.
The problem with XML are also inherent in JSON and every other text-based format; it builds it information-model on a thin but heavy and slippering layer of text. If you've further tried using authenticated e-mails through S/MIME or PGP, you probably seen yet a few.
Anyone using a non-ASCII-language have seen one of the issues of all current text-based formats first-hand; encoding. Text-based isn't actually a guarantee for anything, since it's not a single specification, but rather a dim view of something that is probably ASCII-compatible. (But not necessarily.)
One of the most obvious examples of this is SVG and SOAP. Both in SVG and SOAP, there is a frequent need to transfer some non-text data such as embedded bitmaps, integers, floats and possibly other elements. Done over XML (or any text-based format) this immediately becomes a very big task passing through layers of text-encoding, lexical analysis, semantical analysis, DOM-construction (not necessary with a SAX-parser but that's a it's own story), the assumption that integers will be decimal written in small-endian, and finally back to the data-structure that it actually was at the beginning. Then you're ready to actually start with the real interpretation of the data.
Alternatively, say it's an array of integers, say "here comes 320 32-bit unsigned integers" and just send them (in network-endianess). A LOT less error-prone, a LOT faster, and a LOT easier on both ends. Alternatively, say "here comes a 4mbyte bitstream" and just transfer your image. In that way, the parser may even skip the 4mbytes, since it's not really looking for the image right now. Finally, but possibly most important, if you want to transfer some text, you say "here comes 48bytes of UTF-8 text" and then send it. This way, whomever reads this will KNOW how the text is encoded, and be able to do something sensible with it, as opposed to mere guessing.
As an example of the charset-issues, just consider that in a standard XHTML-document, there will be 3 possible places to tell the client what encoding to use, and no guarantee any of them will match. First, the HTTP-header, secondly in the XML-declaration and finally in the Meta-tags. To show the problem, look at the first example of http://www.webreference.com/authoring/xhtml/coding/, where even a page trying to explain it gives of an incorrect example without mentioning the error. JSON does it slightly better, determining that all content should be encoded in a Unicode-encoding avoiding some of the issues, but instead facing the issues of Unicode http://en.wikipedia.org/wiki/Unicode#Issues.
So, while I agree on XML being way to heavy-wheight, I don't see JSON to be the solution, still being built on text.
Well, mov isn't available on Windows without additional software the last time I tried it. Neither on Linux. I suspect it's still the case with MPEG-4 as well, not available on Windows without additional software, and on Linux not legally available at all in many countries.
.MOV deals with this, as I can't find any references.
And I wouldn't say this being a OS-matter either, or at least shouldn't be. Since no browser supports HTML5 at all yet, what's available on the platforms TODAY now are relatively uninteresting, compared to the ease with which the formats CAN be implemented in order to comply with HTML5. Most of the formats are covered by patents and license fees, which makes them, even if not technically hard, practically close to impossible to implement in many platforms, especially free software.
Also, a standard such as the web should not depend on licensed technology. (At least not IMHO) This is where the Xiph-patents have an edge. They are, at least supposedly, not encumbered by patented technology and thus free for use by anyone. They've also got a freely portable implementation, which can easily be incorporated into browsers. There may be other formats that fits by the same arguments, and if so they should also be considered.
Regarding streaming of different codecs, resolutions and bitrates, this is handled by RTSP and RTP, and IMHO should stay there. (No point in having to download parts of the content you don't want.) I'm not sure how you mean
My basic standpoint: Since Audio/Video and streaming is becoming an essential part of the web, a list of recommended formats and codec are needed to ensure standards-based interoperability. An internet standard should not depend on licensed technology, and thus, Xiph codec are one logical candidate for recommendation. (And yes, I too would like to see a trial of the true Legal State of Xiph-codecs.)
Not necessary at all. The point of a standardized format is to allow content creators publish their content in a format they know most of the audience will be able to support.
.psd-files in your image-tags. In the same way, there should be one or a couple of standardized formats for video that can be assumed by the content creator to be supported by the browser.
In the case of images, you don't usually require the user to download "Photoshop Viewer Plugin" so you can embed
If you then for some technical reason/preference require support for different formats, it's essential for the specification to allow extensions. I.E. allow special plugins to support FairPlay-DRM in order to sell movies on their sites.
But again, just like images, there should be "standard" content formats to fall back on for maximal compatibility.
Sorry, but I think this belief is flawed. Many payloads for different types of automated attacks such as trojans and worms today are smart enough to be dynamic and handle many different environments. I.e. they detect what mailer you're using and use it to send spread it's word, to add authenticity. It detects what I'm, what addressbook and what browser you're using, to skim for passwords and similar to mail back to it's master etc.
I think worms, soon if not already will contain detection mechanisms to exploit a variety of hypervisors. If nothing else, it will most likely be able to crunch some numbers (say, it's part of the storm botnet) and dehash your admin p/w which for most systems will be the same in all servers.
Actually, he based it on previous relations with his maintainer. Right or wrong, that was probably the no.1 reason.
One vote for drugs.