Didn't mean to suggest that it was named after him, but rather developed by Ericsson the company, in house. The name is "deliberately ambiguous" according to someone who should know. (http://www.cs.chalmers.se/Cs/Grundutb/Kurser/ppxt/HT2007/general/languages/armstrong-erlang_history.pdf at 3.2)
Indeed the website for the language is "golang" just as ericsson is to ERlang, google is to GOlang. Seems maybe an OO corollary to erlangs functional paradigm. Will have to look deeper. I do love a new language,
I looked hard at netezza for a big project with "absurd" requirements (many 10^4 new records per second, ad hoc queryable by clients). It seemed to be the ideal solution. Nice to see it might have worked. How fast does your data grow?
I actually had this experience in my new Mazda2. It was quite scary. I was going up a steep hill and the engine revved a little higher than normal, I did a bit of gear changing (it is an auto) and the revving continued, as I pulled up to the queue of traffic at the lights at the top of the hill (with the massive truck behind me!). It was all getting out of control. What was weird was that the throttle was still responsive, depress it, the engine revved up, back off it de-revved, but back to well above idle.
I too was worried about the engine electronics, until I checked the floor mat and found it had slid up over the base of the accellerator, pulled the mat back and all was ok. All in all probably about a minute but very disturbing at the time. I can totally see the source of an accident in such an event. It really felt like an electronic issue at the time, until I realised what it actually was.
The.NET platform is a generic platform that is capable of delivering good or at least acceptable performance in most cases.
Indeed. And this has been my point about the "new technologies" for a few years (specifically in the Stock Exchange space but also more generally). These new languages and platforms have lowered the barriers to creating average, adequate systems. If you use excellent people to do good design then you can really lower the implementation and operation costs of these systems and produce excellent applications. By excellent I mean cheap and fast and good or perhaps rather a triangle of cheap, fast and good that has much shorter vertices than the traditional model which makes the overall compromise easier to bear.
BUT, and it is a huge BUT. These systems cannot survive at the edges of performance. You give up too much control to the "framework" regardless of which one it is;.NET, Java, Smalltalk, Rails, whatever. As a result you cannot approach the limits of performance of the hardware at your disposal. Stock exchanges are, by their very nature a shared resource, minimum latency problem which means that every CPU cycle you are not using doing _real_ work is someone not getting serviced as well as the next guy. It is hoped that when you do the design and implementation right, you can take this tradeoff below the threshold of caring for the participants of your market.
At the top end of these systems you have to be using haute design and implementation to cut it.
A comparison that might shed light is cars, family sedan, Ferrari, F1. The family sedan of today is a highly efficient, cheap and really very good quality implementation of a car, but it just can't compete with a Ferrari on performance and whilst a Ferrari will get close to an F1 in many aspects of performance all the extra engineering in the F1 car is designed to wring out the last iota of performance that means that no matter how good the Ferrari is, it can _never_ get any closer to the F1 car. (As a sidelight note that the failures that result from a fault in each of these types of vehicles probably correlates to what goes wrong in the system space as well, not pretty!!).
As such, any system written within the constraints of a "Consultancy/Outsourced/Managed Code" environment simply cannot be at the leading edge of performance.
It is interesting to try and compare the characteristics of a Trading System with other more traditional HPC applications for which supercomputers would ordinarily be used as well as with other high requirement problems. I recall looking at VISAs data processing throughput and on their busiest day in history (23rd of December 2006 IIRC) they processed 180 million transactions in a day), and their IT spend was phenomenal. O can't find that data just now but in the year to June 30 2009, VISA processed just under 40 billion transactions, that translates to about 1300 per second. A stock exchange is an order of magnitude more transactions than that (perhaps more depending on how you count it) and the handful of seconds you wait at the Checkout for your VISA payment to authorise is 4 orders of magnitude longer than a stock exchange requires (10 seconds compared to 1/1000 of a second). That means that a stock exchange is constrained in two dimensions by a total of 5 orders of magnitude more demanding requirements than a system as comprehensive as VISA. I have no real experience about a climate model or nuclear simulation, but I get the feeling that it is a huge dataset issue and your "release valve" is that whilst execution time is ideally to be reduced, the simulation takes as long as it takes and you wait until it is done. CErtainly more Gigaflops than a Stock Excahnge but not as demanding in terms of the number or rigour of the contraints under which you must operate.
To make that work, you kinda need to be down at the metal.
To make sure that you also make it work 100% of the time you need to be bloody caref
If you're over 300 kilometers away from the server, a one-way transaction will take more than 1 millisecond at the speed of light anyway. If millisecond gaps were that important, you'd hear about global disparities directly related to distances from the stock exchange servers.
Which is why whenever a client asks that exact question about how distance affects the "customer experience" of my sub millisecond trading system, I tell them - move closer. Not only is it a serious answer, but almost all the serious performance exchanges are offering co-location services to get the client systems on the same LAN yet alone on the same backplane.
IIRC correctly there are event some patents about co-locating the client algorithm inside the exchange trading system itself (broadly speaking). Although I am certain that if my recollection is correct then there is no formal implementation of this idea. It's something I have toyed with myself for a number of years. Kinda funky. If you can manage the risk of a rogue client, it's a trader's nirvana.
The insanity was not "Windows". Trading systems use very few OS based services. As I have said before, they basically need TCP stack and some pretty basic IPC, the extent to which Windows is good enough to provide this is debatable but it is not obviously insance. The tuning of the OS to make these limited services screamingly fast is the point at which something like GNU/Linux has benefits in my experience.
Ah yes, Sun and finance, They certainly shipped a lot of pizza boxes when PA RISC was the only non-IBM Unix equivalent, but in those days it was probablem tandem that was a more important player in the stock exchange space. Interestingly I think it was as much if not more intel rather than GNU/Linux that has driven Sun out of the machine rooms. Perhaps the Linux/Intel nexus is too hard to unwind to make that call tho'.
Except when the author takes a stroke of genius to avoid the technobable issues, a la "Dune", where Herbert, writing in the late 60s avoids the problem of where computers would be in 10,000 years by having them "banned" and deals with FTL travel by making it a monopoly supplied service. Similar genius with Nukes and "friggin' lasers". My point is that the "Lit" analysis of these techniques is thoroughly worth doing since it can help to make timeless future worlds and allow the student to understand what works and what doesn't.
Similary I find the absurd scope of something like Greg Bear's "Moving Mars" or "Forge of God/Anvil of Stars" to be equally as disarming because the scope of the tech is so bizarre that it is about the surrounding story rather than whether the tech might actually work.
Haven't bought a real DVD for 10 years (I bought a couple of 99c clangers as a joke present, even then technically it was someone elses money!). Won't ever buy one again until this madness ends.
On the contrary, by way of example. If, in good faith, you buy some timber and use it to build a house, subsequently it is shown that the timber was stolen, it is very rare that the courts will make you pull down your house. The public policy implicatons of that result would be undesirable.
In this case the guy in question has clearly suffered loss as a result of Amazon's negligence (and that would be an interesting twist on his course of action, to couch it in terms of negligence!!), I hope he wins and wins big. Amazon should be punished for this kind of unilateral action. It's just soooo wrong to take back without checking first.
Whilst the ones you mention have intense processing requirements, they are fundamentally different to Stock Exchanges. Indeed in many ways they are vastly more demanding that Exchanges but in two critical ways; uptime/integrity and response time, an exchange is horribly, horribly demanding.
Being up 99.9% of the time is wonderful, getting to 99.99% takes another order of magnitude spend. Getting to Exchange level 99.999% takes another order of magnitude spend (sort of). Given a 12 hour business day 99.99 means about 18 minutes of downtime a year. Now realistically this means 1 downtime event every three years. That means zero downtime events and every transaction coming through the system has the potential to be legally binding and worth millions, oh and the customer demands a guarantee that the response time will be less than 10 milliseconds (increasingly less than a millisecond). And this is just for a simple equity market. It only gets more complicated from there.
I am not suggesting that Linux is not the answer (indeed I advocate it in the exchange problem domain myself), just that the lessons that Google, Yahoo and Amazon have to teach this problem domain are limited and Windows can be made to work in the environment.
I was involved in discussions (and more) with the LSE before (during but not so much) and after they decided to select Microsoft / Accenture / India / Outsourcing as the path for their solution and I know some of the key decision makers. Under the Microsoft umbrella, they were significantly influenced by the resources Microsoft was willing to commit to making the project work despite the newness of.NET as an ifrastructure.
It is important to remember where the LSE was before the TradeElect project, they had completely outsourced their platform to Accenture, the amount they spent per annum on keeping that platform up and running were phenomenal, an order of magnitude more than some of our clients were spending and they (our clients) were running much higher performance systems. TradeElect was designed to decrease these costs without compromising the "I don't lose sleep at night worryin about the systems" position of senior managers. I firmly believed it was a mistake to believe that.NET at the heart of the platform would meet the requirements of an exchange trading platform.
I have no real issue with Windows as the OS under the platform, really for a trading system the OS is providing a TCP stack and some IPC and thats about it. Everything else and the vast majority of the bottlenecks are in your application stack, whether it be tools or application code you are writing for your specific problem domain. Although one might argue that the Microsoft IPC tools can be argued as "weak/complicated".
It will be interesting to see which people the LSE use to provide the analysis of which way to jump with this decision. Too many very senior folk were involved all the way through the TradeElect project for heads to roll, but it will be interesting to watch who says what when the final decision of what to do is announced.
You even link to the site of Liberty, a group that actively monitors, publishes and criticises the policies and practices of the government of which you speak and is based in the same freakin' country. If you fear "erosion of privacy" then why on earth do you fear a Tory government, they should be your best friend? You have just had a huge scandal about the rorting of your MPs funding and there is a strong tradition (important with the kind of constitution in the UK) of privacy and reaction to government intervention.
Why would you want the withdrawal and balance check to run concurrently?
Because I can do a whole lot of "local" withdrawal processing whilst my balance check is off checking the canonical source of balance information. If it's comes back OK then the work I have been doing in parallel is now commitable work and my transaction is done. Perhaps in no more time than either of the balance check or the withdrawal whichever is the longest. Whilst the balance check/withdrawal example may seem ridiculous. There are some very interesting applications of this kind of problem in securities (financial) trading systems where the canonical balances of different instruments would conveniently (and some times mandatorily) stored in different locations and some complex synthetic transactions require access to balances from more than one instrument in order to execute properly.
It seems to me that most of the interesting parallism problems relate to distributed systems and it is not just a question of N phase commit databases but rather a construct of "end to end" dependencies in your processing chain where the true source of data cannot be accessed from all the nodes in the cluster at the same time from a procedural perspective.
It is this fact that to me suggests that the answer to these issues is a radical change in language toward the functional or logical types of languages like haskel and prolog with erlang being a very interesting place on that path for right now.
When a company wants to buy you, it means you are competitors otherwise and they want to stop you or otherwise control your future.
Not so. I have been involved in several cases where the acquisition was not to stifle a competitor but rather to;
Move up the value chain
Acquire complementary businesses
Acquire skills and expertise
There are other reasons as well and of course we have also been invloved in acquisitions within the same primary business to increase market share, similar to your case above. In these cases, depending on the market in question, there are issues of price to be paid. Particularly if the market has only few competitors. This is very unlikely in the case at point.
My advice to the prospective recipient of a buyout is to price all the things they value about working for themselves and then discount them from the purchase and prepare to lose control of their business within 5 years (and price that as well). The thinking here is that with megacorp behind you you will be driven by the kind of medium size company management issues like revenue growth and cost control for which you are not currently prepared and which are frequently the cause of "ructions" between the current principles and new bosses. Many folk leave as a result of these ructions, by choice or by squeezed out. The five year time frame is used because it should include a decent "downturn" in the overall economy and hence a good old stresser of the management team.
On the other hand one or more of your group might enjoy the opportunities that Megacorp present, each of you should price these things independently and the talk about your differences.
You kind of need to be unanimous. A majority vote will likely be a disaster.
Then why not get a proper transit system. Kill one lane of your freeway and make it bus only. Use trunk and local services. One change is not unreasonable. So...
Large busses going from CBD to distant node on dedicated express lanes. Ideally this would take less than half the time of what I would understand as "peak time" driving. Then split that set of passengers in to N smaller multi stop vehicles, maybe as much as 20 seats, certainly no more.
You are home in much less time and this kind of services scales well for peak loads. In addition the "remote" end small bus service would work well as a bus priced "call and collect" service from your home to the local area community destinations such as mall, supermarket, rec centre or other such.
Old public transport systems were inherently driven by fixed routes, particularly rail and light rail services. As many have pointed out this does tend to demand a certain population density to be viable. However route planning and communications technology has some a long way and trunk and leaf transport systems built around "call and collect" local services can really solve the issues for places lie the US where the population density does not hit the threshold. This is increasingly true with aging populations making driving less and less viable.
When hiring "no experience recruits", a degree was a critical selector for me. If you can show that you were willing to go through the 3 years of ups (and particularly downs) to get a degree then you are showing a willingness to take the medium to long term view of something. I wanted this in my people.
Your Resume would stick out from the crowd if I were reading it, due to "starting CS at 30" and I would want to know why. Whilst personally I would probably find the phrase "Pissed away my 20s" entertaining in a Resume (it would certainly get your Resume passed the first cull for me) it is probably not true for most. But there is real value in the experience that you have gathered if you can "spin" it right. Particularly since the 3 years to get the degree shows that any delay is unlikely to show complete flakiness on your part. Get a degree from an excellent institution, even better. The quality of the institution is actually quite important. If I have 100 resumes to pass through the first cull into 20 that we might pass around internally to find 5 or 10 to interview then the quality of your degree (GPA, pass level, institution) will be a factor.
As for the ageism, yep, its real. You are a much more formed person at 30 - 35 than 21 - 23 (the age of the other recent recruits). More formed means more issues. Not that there is always a direct intent to "form" employees. Just a subconscious knowledge that older means more idiosyncracies (sp?). Plus you are much more likely to need more wages sooner in terms of family and Life planning needs. All these are factors that increase the likelihood you will have an issue for me to manage. That is not to say the younglings don't have their own issues but they are more likely to be the common ones and we have seen most of them before.
Again this just means spin you Resume. Don't lie, the kind of employer you want will detect them. Just be frank and make the glaring fact of your age and lack of direct experience something of which you are aware as well as them and they will much more happily discount it.
I have been responsible for hiring several tens of people over the last decade or so, so I have seen hundreds of Resume and conducted many, many interviews (oh so many interviews). Several hires were late-comers to the CS field (PhD in unrelated fields, Working history and CS conversion degrees or like yourself) and many were less than 2 years experience. We had great success with many of our older latecomers but the trick is to get passed the Resume cull and into the interview room. Some of the ideas above might help you there.
And all without managed memory, automatic garbage collection, etc., imagine that! Seriously, I see so many devs (and M$, who has a product to sell) insisting that all that junk is what will save us. What they're doing is attempting to create a Fisher Price dev environment where you don't have to think anymore because they've done it all for you. What's going to happen to this world when GenC# programmers replace the old guard and they don't have the least clue about what is going on inside the computer that makes the magic happen?
And more power to them because there are a hell of a lot of applications that can be written that way (by that way I mean with the training wheels on "insert tab a into slot 27" style) and they should be written that way. Maybe even written by those people. But, and it is a big but, there are other applications that need the kind of knowledge of which you speak. It is "hard" (certainly compared to the fisher price model) and hence it is expensive. It is also mostly interesting and so it is where I want to apply my skills, and hopefully receive the comensurate compensation.
I have spend about 15 years designing systems for the financial markets and almost without fail, at first instance, a customer will say "Such and such" an event is really important and the User must have something pop up and tell them. Well, it isn't.
What I mean is that you really need to understand the "workflow" of a given situation and given that understanding it is almost always true that one should never interrupt the work that a User is currently doing with something that they "must" do to proceed. All you will do is annoy them.
In every situation I encountered above, the customer came to understand why interrupting the workflow is never a good idea.
These notifications are a good idea from that perspective. Besides if something really is "that important" there will be a better way of managing it than these kinds of things.
What is interesting to me is the question of what is the best way to make these notofications appear. Again in the environment with which I am familiar, the "ticker" model seems to be a strong one. The most common implementation being a "page" (sometimes very small) of messages scrolling by with colour being used to indicate importance/severity/careworthyness. I reckon that the mock up shown is pretty good but I suspect that "colour coding" is a useful/necessary addition.
It is even simpler than that. Let the teacher grade. With the instruction that it should be to, say; a mean of 60 and SD of 20. Then submit all these grades to adjustment by the relative performance of your class in the subsequent public examination involving all students in the "system"
If your class are predominantly geniuses that averaged 85 (with and SD of 5) in the state wide exam then the 40 you got in class will become 75 (ish). Similarly if the teacher grades too easily it shows up real fast in the data.
The broad based public examination is the solution to these problems you just need to be allowed to know the results and this is where the teachers get in a lather 'cause it shows the useless ones up to be, well, useless. God forbid!!
That's the whole problem. You shouldn't be learning what 13 * 7 is. You should be learning how to multiply two numbers together.
Actually there is a good argument for learning 13*7 (well at least 12*7) so that when you buy a dozen 70p cream buns for £8 you know you are getting value for money without spending five minutes holding up the line for the rest of us.
Moreover, learning how to multiply two numbers is much less important than understanding why multiplication works at all. If one understands the first principles, for example the Commutitative, Associative or Distributive laws then one is far better equipped to handle new and interesting areas of endeavour. Notice that all of those laws are valuably demonstrated without the need to refer to numerical examples.
I am no defender of the school system but it is presumptions about the value of stupid human tricks, like life skills "times tables" and the "point at which to stop reduction" in teaching fundamentals is the reason why my Dad can't set a digital clock on the microwave and my 2 year old nephew can turn on the TV and DVD player to watch Ben 10 or his 5 year old brother can fire up a web browser and play some stupid flash Lego(tm) game.
This is true but what is critical is to ask yourself why this is a difficult concept. As with most education it is important to start with the first principles.
Now with computing there are two places from which these principles start.
1) the underlying computer 2) the formal mathematics of computing
Now given that these students are very unlikely to be at a level where the formal mathematics of computing is accessible then start with the underlying computer.
Almost everything about programming, even the internet, can be easier to understand if you understand about Memory, stack, registers, the program counter etc. I am not suggesting that you should teach machine language but the "box example" above is still and abstract representation of the _reason_ why all this is necessary.
With the idea of needing to load memory into registers to perform the basic "add and store" of computation in mind it gives you an anchor on which any of the more advanced topics can be hung. For example from memory allocation in C to garbage collection in Java, from malloc to nibble memory.
The other really important thing to emphasise (in my view maybe the most important) is that the implementation language is not important for the learing of the principles. For whilst you may well want to concentrate on a single implementation language to make youre life easier there are some superb lessons in showing the same problem solved in different languages.
My favourite story in this area is the problem to partition N integers into two groups so that each group's sum is the same (the "partitioning problem"). Write an implementation in C, X lines of code, probably hundreds. Write it in, say, prolog, 40 lines of code. Now make it the "N partitioning problem" ie instead on 2 make it N groups with the C code the problem is now much more complicated. With prolog it's one more line of code.
As far as practical tasks go, classically sorting is a good example because it is an easy concept to grasp and so easy to implement in so many ways in so many languages. So you can show the difference between algorithm and implementation again such a critical lesson to have learnt as soon as possible.
I too was initially tempted to call bullshit but it seems that (http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-September/016284.html) it's the real deal. Worrying but not something over which to lose too much sleep, yet!, since finding the exploit is the problem.
Re:And you were expecting what?
on
Tech Vs. Business?
·
· Score: 3, Informative
Maybe I was lucky, but more than a dozen years delivering major financial market projects and our project managers were always the good kind you describe above and the client always understood the time (and sometimes money) impact of Changes.
HOWEVER, this was because we had, by this time, always established the trust between client and IT provider that meant;
a) If we say "that's hard/expensive" it's because it is "hard" or "expensive"
b) We did everything the client wanted to the extent that it did not compromise the success of the project. Success is a great motivator for the most flakey of clients
In addition since we were an outside vendor (not just an internal IT department) we had the luxury of using price to focus the mind of those that would otherwise be changeable.
What is intersting is that many of the clients in question had professional project managers themselves and despite the trials and tribulations along the way it was always a case of everyone being aware of what was necessary to get the project over the line.
These project invariably would make front page news in the country in question in the event of a failure (finance pages at least:-) so the incentive was high.
I think that is the key. Incentivise everyone to get the project live and it becomes more feasible that the project will succeed
Slashdot Mirror
Didn't mean to suggest that it was named after him, but rather developed by Ericsson the company, in house. The name is "deliberately ambiguous" according to someone who should know. (http://www.cs.chalmers.se/Cs/Grundutb/Kurser/ppxt/HT2007/general/languages/armstrong-erlang_history.pdf at 3.2)
Indeed the website for the language is "golang" just as ericsson is to ERlang, google is to GOlang. Seems maybe an OO corollary to erlangs functional paradigm. Will have to look deeper. I do love a new language,
I looked hard at netezza for a big project with "absurd" requirements (many 10^4 new records per second, ad hoc queryable by clients). It seemed to be the ideal solution. Nice to see it might have worked. How fast does your data grow?
I actually had this experience in my new Mazda2. It was quite scary. I was going up a steep hill and the engine revved a little higher than normal, I did a bit of gear changing (it is an auto) and the revving continued, as I pulled up to the queue of traffic at the lights at the top of the hill (with the massive truck behind me!). It was all getting out of control. What was weird was that the throttle was still responsive, depress it, the engine revved up, back off it de-revved, but back to well above idle.
I too was worried about the engine electronics, until I checked the floor mat and found it had slid up over the base of the accellerator, pulled the mat back and all was ok. All in all probably about a minute but very disturbing at the time. I can totally see the source of an accident in such an event. It really felt like an electronic issue at the time, until I realised what it actually was.
The .NET platform is a generic platform that is capable of delivering good or at least acceptable performance in most cases.
Indeed. And this has been my point about the "new technologies" for a few years (specifically in the Stock Exchange space but also more generally). These new languages and platforms have lowered the barriers to creating average, adequate systems. If you use excellent people to do good design then you can really lower the implementation and operation costs of these systems and produce excellent applications. By excellent I mean cheap and fast and good or perhaps rather a triangle of cheap, fast and good that has much shorter vertices than the traditional model which makes the overall compromise easier to bear.
BUT, and it is a huge BUT. These systems cannot survive at the edges of performance. You give up too much control to the "framework" regardless of which one it is; .NET, Java, Smalltalk, Rails, whatever. As a result you cannot approach the limits of performance of the hardware at your disposal. Stock exchanges are, by their very nature a shared resource, minimum latency problem which means that every CPU cycle you are not using doing _real_ work is someone not getting serviced as well as the next guy. It is hoped that when you do the design and implementation right, you can take this tradeoff below the threshold of caring for the participants of your market.
At the top end of these systems you have to be using haute design and implementation to cut it.
A comparison that might shed light is cars, family sedan, Ferrari, F1. The family sedan of today is a highly efficient, cheap and really very good quality implementation of a car, but it just can't compete with a Ferrari on performance and whilst a Ferrari will get close to an F1 in many aspects of performance all the extra engineering in the F1 car is designed to wring out the last iota of performance that means that no matter how good the Ferrari is, it can _never_ get any closer to the F1 car. (As a sidelight note that the failures that result from a fault in each of these types of vehicles probably correlates to what goes wrong in the system space as well, not pretty!!).
As such, any system written within the constraints of a "Consultancy/Outsourced/Managed Code" environment simply cannot be at the leading edge of performance.
It is interesting to try and compare the characteristics of a Trading System with other more traditional HPC applications for which supercomputers would ordinarily be used as well as with other high requirement problems. I recall looking at VISAs data processing throughput and on their busiest day in history (23rd of December 2006 IIRC) they processed 180 million transactions in a day), and their IT spend was phenomenal. O can't find that data just now but in the year to June 30 2009, VISA processed just under 40 billion transactions, that translates to about 1300 per second. A stock exchange is an order of magnitude more transactions than that (perhaps more depending on how you count it) and the handful of seconds you wait at the Checkout for your VISA payment to authorise is 4 orders of magnitude longer than a stock exchange requires (10 seconds compared to 1/1000 of a second). That means that a stock exchange is constrained in two dimensions by a total of 5 orders of magnitude more demanding requirements than a system as comprehensive as VISA. I have no real experience about a climate model or nuclear simulation, but I get the feeling that it is a huge dataset issue and your "release valve" is that whilst execution time is ideally to be reduced, the simulation takes as long as it takes and you wait until it is done. CErtainly more Gigaflops than a Stock Excahnge but not as demanding in terms of the number or rigour of the contraints under which you must operate.
To make that work, you kinda need to be down at the metal.
To make sure that you also make it work 100% of the time you need to be bloody caref
If you're over 300 kilometers away from the server, a one-way transaction will take more than 1 millisecond at the speed of light anyway. If millisecond gaps were that important, you'd hear about global disparities directly related to distances from the stock exchange servers.
Which is why whenever a client asks that exact question about how distance affects the "customer experience" of my sub millisecond trading system, I tell them - move closer. Not only is it a serious answer, but almost all the serious performance exchanges are offering co-location services to get the client systems on the same LAN yet alone on the same backplane.
IIRC correctly there are event some patents about co-locating the client algorithm inside the exchange trading system itself (broadly speaking). Although I am certain that if my recollection is correct then there is no formal implementation of this idea. It's something I have toyed with myself for a number of years. Kinda funky. If you can manage the risk of a rogue client, it's a trader's nirvana.
The insanity was not "Windows". Trading systems use very few OS based services. As I have said before, they basically need TCP stack and some pretty basic IPC, the extent to which Windows is good enough to provide this is debatable but it is not obviously insance. The tuning of the OS to make these limited services screamingly fast is the point at which something like GNU/Linux has benefits in my experience.
Ah yes, Sun and finance, They certainly shipped a lot of pizza boxes when PA RISC was the only non-IBM Unix equivalent, but in those days it was probablem tandem that was a more important player in the stock exchange space. Interestingly I think it was as much if not more intel rather than GNU/Linux that has driven Sun out of the machine rooms. Perhaps the Linux/Intel nexus is too hard to unwind to make that call tho'.
Except when the author takes a stroke of genius to avoid the technobable issues, a la "Dune", where Herbert, writing in the late 60s avoids the problem of where computers would be in 10,000 years by having them "banned" and deals with FTL travel by making it a monopoly supplied service. Similar genius with Nukes and "friggin' lasers". My point is that the "Lit" analysis of these techniques is thoroughly worth doing since it can help to make timeless future worlds and allow the student to understand what works and what doesn't.
Similary I find the absurd scope of something like Greg Bear's "Moving Mars" or "Forge of God/Anvil of Stars" to be equally as disarming because the scope of the tech is so bizarre that it is about the surrounding story rather than whether the tech might actually work.
They want their uneducated underclass back to grind into the machinery of the economy.
Haven't bought a real DVD for 10 years (I bought a couple of 99c clangers as a joke present, even then technically it was someone elses money!). Won't ever buy one again until this madness ends.
On the contrary, by way of example. If, in good faith, you buy some timber and use it to build a house, subsequently it is shown that the timber was stolen, it is very rare that the courts will make you pull down your house. The public policy implicatons of that result would be undesirable.
In this case the guy in question has clearly suffered loss as a result of Amazon's negligence (and that would be an interesting twist on his course of action, to couch it in terms of negligence!!), I hope he wins and wins big. Amazon should be punished for this kind of unilateral action. It's just soooo wrong to take back without checking first.
Whilst the ones you mention have intense processing requirements, they are fundamentally different to Stock Exchanges. Indeed in many ways they are vastly more demanding that Exchanges but in two critical ways; uptime/integrity and response time, an exchange is horribly, horribly demanding.
Being up 99.9% of the time is wonderful, getting to 99.99% takes another order of magnitude spend. Getting to Exchange level 99.999% takes another order of magnitude spend (sort of). Given a 12 hour business day 99.99 means about 18 minutes of downtime a year. Now realistically this means 1 downtime event every three years. That means zero downtime events and every transaction coming through the system has the potential to be legally binding and worth millions, oh and the customer demands a guarantee that the response time will be less than 10 milliseconds (increasingly less than a millisecond). And this is just for a simple equity market. It only gets more complicated from there.
I am not suggesting that Linux is not the answer (indeed I advocate it in the exchange problem domain myself), just that the lessons that Google, Yahoo and Amazon have to teach this problem domain are limited and Windows can be made to work in the environment.
I was involved in discussions (and more) with the LSE before (during but not so much) and after they decided to select Microsoft / Accenture / India / Outsourcing as the path for their solution and I know some of the key decision makers. Under the Microsoft umbrella, they were significantly influenced by the resources Microsoft was willing to commit to making the project work despite the newness of .NET as an ifrastructure.
It is important to remember where the LSE was before the TradeElect project, they had completely outsourced their platform to Accenture, the amount they spent per annum on keeping that platform up and running were phenomenal, an order of magnitude more than some of our clients were spending and they (our clients) were running much higher performance systems. TradeElect was designed to decrease these costs without compromising the "I don't lose sleep at night worryin about the systems" position of senior managers. I firmly believed it was a mistake to believe that .NET at the heart of the platform would meet the requirements of an exchange trading platform.
I have no real issue with Windows as the OS under the platform, really for a trading system the OS is providing a TCP stack and some IPC and thats about it. Everything else and the vast majority of the bottlenecks are in your application stack, whether it be tools or application code you are writing for your specific problem domain. Although one might argue that the Microsoft IPC tools can be argued as "weak/complicated".
It will be interesting to see which people the LSE use to provide the analysis of which way to jump with this decision. Too many very senior folk were involved all the way through the TradeElect project for heads to roll, but it will be interesting to watch who says what when the final decision of what to do is announced.
You even link to the site of Liberty, a group that actively monitors, publishes and criticises the policies and practices of the government of which you speak and is based in the same freakin' country. If you fear "erosion of privacy" then why on earth do you fear a Tory government, they should be your best friend? You have just had a huge scandal about the rorting of your MPs funding and there is a strong tradition (important with the kind of constitution in the UK) of privacy and reaction to government intervention.
You, human, are clearly an idiot.
The example in the article is atrocious.
Why would you want the withdrawal and balance check to run concurrently?
Because I can do a whole lot of "local" withdrawal processing whilst my balance check is off checking the canonical source of balance information. If it's comes back OK then the work I have been doing in parallel is now commitable work and my transaction is done. Perhaps in no more time than either of the balance check or the withdrawal whichever is the longest. Whilst the balance check/withdrawal example may seem ridiculous. There are some very interesting applications of this kind of problem in securities (financial) trading systems where the canonical balances of different instruments would conveniently (and some times mandatorily) stored in different locations and some complex synthetic transactions require access to balances from more than one instrument in order to execute properly.
It seems to me that most of the interesting parallism problems relate to distributed systems and it is not just a question of N phase commit databases but rather a construct of "end to end" dependencies in your processing chain where the true source of data cannot be accessed from all the nodes in the cluster at the same time from a procedural perspective.
It is this fact that to me suggests that the answer to these issues is a radical change in language toward the functional or logical types of languages like haskel and prolog with erlang being a very interesting place on that path for right now.
When a company wants to buy you, it means you are competitors otherwise and they want to stop you or otherwise control your future.
Not so. I have been involved in several cases where the acquisition was not to stifle a competitor but rather to;
There are other reasons as well and of course we have also been invloved in acquisitions within the same primary business to increase market share, similar to your case above. In these cases, depending on the market in question, there are issues of price to be paid. Particularly if the market has only few competitors. This is very unlikely in the case at point.
My advice to the prospective recipient of a buyout is to price all the things they value about working for themselves and then discount them from the purchase and prepare to lose control of their business within 5 years (and price that as well). The thinking here is that with megacorp behind you you will be driven by the kind of medium size company management issues like revenue growth and cost control for which you are not currently prepared and which are frequently the cause of "ructions" between the current principles and new bosses. Many folk leave as a result of these ructions, by choice or by squeezed out. The five year time frame is used because it should include a decent "downturn" in the overall economy and hence a good old stresser of the management team.
On the other hand one or more of your group might enjoy the opportunities that Megacorp present, each of you should price these things independently and the talk about your differences.
You kind of need to be unanimous. A majority vote will likely be a disaster.
Then why not get a proper transit system. Kill one lane of your freeway and make it bus only. Use trunk and local services. One change is not unreasonable. So...
Large busses going from CBD to distant node on dedicated express lanes. Ideally this would take less than half the time of what I would understand as "peak time" driving. Then split that set of passengers in to N smaller multi stop vehicles, maybe as much as 20 seats, certainly no more.
You are home in much less time and this kind of services scales well for peak loads. In addition the "remote" end small bus service would work well as a bus priced "call and collect" service from your home to the local area community destinations such as mall, supermarket, rec centre or other such.
Old public transport systems were inherently driven by fixed routes, particularly rail and light rail services. As many have pointed out this does tend to demand a certain population density to be viable. However route planning and communications technology has some a long way and trunk and leaf transport systems built around "call and collect" local services can really solve the issues for places lie the US where the population density does not hit the threshold. This is increasingly true with aging populations making driving less and less viable.
When hiring "no experience recruits", a degree was a critical selector for me. If you can show that you were willing to go through the 3 years of ups (and particularly downs) to get a degree then you are showing a willingness to take the medium to long term view of something. I wanted this in my people.
Your Resume would stick out from the crowd if I were reading it, due to "starting CS at 30" and I would want to know why. Whilst personally I would probably find the phrase "Pissed away my 20s" entertaining in a Resume (it would certainly get your Resume passed the first cull for me) it is probably not true for most. But there is real value in the experience that you have gathered if you can "spin" it right. Particularly since the 3 years to get the degree shows that any delay is unlikely to show complete flakiness on your part. Get a degree from an excellent institution, even better. The quality of the institution is actually quite important. If I have 100 resumes to pass through the first cull into 20 that we might pass around internally to find 5 or 10 to interview then the quality of your degree (GPA, pass level, institution) will be a factor.
As for the ageism, yep, its real. You are a much more formed person at 30 - 35 than 21 - 23 (the age of the other recent recruits). More formed means more issues. Not that there is always a direct intent to "form" employees. Just a subconscious knowledge that older means more idiosyncracies (sp?). Plus you are much more likely to need more wages sooner in terms of family and Life planning needs. All these are factors that increase the likelihood you will have an issue for me to manage. That is not to say the younglings don't have their own issues but they are more likely to be the common ones and we have seen most of them before.
Again this just means spin you Resume. Don't lie, the kind of employer you want will detect them. Just be frank and make the glaring fact of your age and lack of direct experience something of which you are aware as well as them and they will much more happily discount it.
I have been responsible for hiring several tens of people over the last decade or so, so I have seen hundreds of Resume and conducted many, many interviews (oh so many interviews). Several hires were late-comers to the CS field (PhD in unrelated fields, Working history and CS conversion degrees or like yourself) and many were less than 2 years experience. We had great success with many of our older latecomers but the trick is to get passed the Resume cull and into the interview room. Some of the ideas above might help you there.
And all without managed memory, automatic garbage collection, etc., imagine that! Seriously, I see so many devs (and M$, who has a product to sell) insisting that all that junk is what will save us. What they're doing is attempting to create a Fisher Price dev environment where you don't have to think anymore because they've done it all for you. What's going to happen to this world when GenC# programmers replace the old guard and they don't have the least clue about what is going on inside the computer that makes the magic happen?
And more power to them because there are a hell of a lot of applications that can be written that way (by that way I mean with the training wheels on "insert tab a into slot 27" style) and they should be written that way. Maybe even written by those people. But, and it is a big but, there are other applications that need the kind of knowledge of which you speak. It is "hard" (certainly compared to the fisher price model) and hence it is expensive. It is also mostly interesting and so it is where I want to apply my skills, and hopefully receive the comensurate compensation.
I think it is an experiment worth doing.
I have spend about 15 years designing systems for the financial markets and almost without fail, at first instance, a customer will say "Such and such" an event is really important and the User must have something pop up and tell them. Well, it isn't.
What I mean is that you really need to understand the "workflow" of a given situation and given that understanding it is almost always true that one should never interrupt the work that a User is currently doing with something that they "must" do to proceed. All you will do is annoy them.
In every situation I encountered above, the customer came to understand why interrupting the workflow is never a good idea.
These notifications are a good idea from that perspective. Besides if something really is "that important" there will be a better way of managing it than these kinds of things.
What is interesting to me is the question of what is the best way to make these notofications appear. Again in the environment with which I am familiar, the "ticker" model seems to be a strong one. The most common implementation being a "page" (sometimes very small) of messages scrolling by with colour being used to indicate importance/severity/careworthyness. I reckon that the mock up shown is pretty good but I suspect that "colour coding" is a useful/necessary addition.
It is even simpler than that. Let the teacher grade. With the instruction that it should be to, say; a mean of 60 and SD of 20. Then submit all these grades to adjustment by the relative performance of your class in the subsequent public examination involving all students in the "system"
If your class are predominantly geniuses that averaged 85 (with and SD of 5) in the state wide exam then the 40 you got in class will become 75 (ish). Similarly if the teacher grades too easily it shows up real fast in the data.
The broad based public examination is the solution to these problems you just need to be allowed to know the results and this is where the teachers get in a lather 'cause it shows the useless ones up to be, well, useless. God forbid!!
That's the whole problem. You shouldn't be learning what 13 * 7 is. You should be learning how to multiply two numbers together.
Actually there is a good argument for learning 13*7 (well at least 12*7) so that when you buy a dozen 70p cream buns for £8 you know you are getting value for money without spending five minutes holding up the line for the rest of us.
Moreover, learning how to multiply two numbers is much less important than understanding why multiplication works at all. If one understands the first principles, for example the Commutitative, Associative or Distributive laws then one is far better equipped to handle new and interesting areas of endeavour. Notice that all of those laws are valuably demonstrated without the need to refer to numerical examples.
I am no defender of the school system but it is presumptions about the value of stupid human tricks, like life skills "times tables" and the "point at which to stop reduction" in teaching fundamentals is the reason why my Dad can't set a digital clock on the microwave and my 2 year old nephew can turn on the TV and DVD player to watch Ben 10 or his 5 year old brother can fire up a web browser and play some stupid flash Lego(tm) game.
This is true but what is critical is to ask yourself why this is a difficult concept. As with most education it is important to start with the first principles.
Now with computing there are two places from which these principles start.
1) the underlying computer
2) the formal mathematics of computing
Now given that these students are very unlikely to be at a level where the formal mathematics of computing is accessible then start with the underlying computer.
Almost everything about programming, even the internet, can be easier to understand if you understand about Memory, stack, registers, the program counter etc. I am not suggesting that you should teach machine language but the "box example" above is still and abstract representation of the _reason_ why all this is necessary.
With the idea of needing to load memory into registers to perform the basic "add and store" of computation in mind it gives you an anchor on which any of the more advanced topics can be hung. For example from memory allocation in C to garbage collection in Java, from malloc to nibble memory.
The other really important thing to emphasise (in my view maybe the most important) is that the implementation language is not important for the learing of the principles. For whilst you may well want to concentrate on a single implementation language to make youre life easier there are some superb lessons in showing the same problem solved in different languages.
My favourite story in this area is the problem to partition N integers into two groups so that each group's sum is the same (the "partitioning problem"). Write an implementation in C, X lines of code, probably hundreds. Write it in, say, prolog, 40 lines of code. Now make it the "N partitioning problem" ie instead on 2 make it N groups with the C code the problem is now much more complicated. With prolog it's one more line of code.
As far as practical tasks go, classically sorting is a good example because it is an easy concept to grasp and so easy to implement in so many ways in so many languages. So you can show the difference between algorithm and implementation again such a critical lesson to have learnt as soon as possible.
I too was initially tempted to call bullshit but it seems that (http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-September/016284.html) it's the real deal. Worrying but not something over which to lose too much sleep, yet!, since finding the exploit is the problem.
Maybe I was lucky, but more than a dozen years delivering major financial market projects and our project managers were always the good kind you describe above and the client always understood the time (and sometimes money) impact of Changes.
HOWEVER, this was because we had, by this time, always established the trust between client and IT provider that meant;
a) If we say "that's hard/expensive" it's because it is "hard" or "expensive"
b) We did everything the client wanted to the extent that it did not compromise the success of the project. Success is a great motivator for the most flakey of clients
In addition since we were an outside vendor (not just an internal IT department) we had the luxury of using price to focus the mind of those that would otherwise be changeable.
What is intersting is that many of the clients in question had professional project managers themselves and despite the trials and tribulations along the way it was always a case of everyone being aware of what was necessary to get the project over the line.
These project invariably would make front page news in the country in question in the event of a failure (finance pages at least :-) so the incentive was high.
I think that is the key. Incentivise everyone to get the project live and it becomes more feasible that the project will succeed