From somebody that DID do C & C++ and has been doing mostly Java for a number of years now:
- Get an experienced Java Developer/Designer/Architect inhouse at least for preparing and doing the migration. Put that person in a team-lead/team-coach role or at the very least use him/her for high-level design and for code reviewings. No mater how good you guys are, when you move to a different language AND more importantly a new set of libraries and frameworks, if you do it on your own you're going to make all the mistakes a "new guy" does which means a lot of going back and forward as you figure out that your initial design doesn't quite work with Hibernate/Spring/J2EE/whatever.
- Develop a couple of some small apps first, just to get some experience with the language itself - take a week or two doing it. Try and use the libraries/frameworks you wanna use in the main project - for example, if you wanna use Hibernate to access the database, do a small app that works with it.
- If some of you guys are still using non-object oriented features from the C side of C++, you're going to have problems moving to Java. The simplest solution is using loads of static methods in an auxiliary class. DON'T! Generic auxiliary methods in Java are the exception, not the rule in most applications.
- Beware of thread safety. Multi-threading is a built-in feature in the standard Java libraries, and when using some of the major frameworks (J2EE for example, both the web side and EJBs) or having to deal with asynchronous events from multiple external entities (for example the server-side of a multiple-user client-server app) it is almost guarante that some of your methods WILL BE called by multiple threads simultaneously. If you make auxiliary methods at the class level (or worse, in a generic class), beware of them keeping state - in a multi-threaded environment there is no guarantee that said methods will be called in any given order, even if the your code looks like it will never do otherwise. The only way to control multi-threaded access to resources that have state is to either not share them (ie put the auxiliary methods in an object or encapsulate state in an object that gets passed to the methods) or carefully using synchronized blocks and methods (very few people know how to do the last one properly). Fortunatly, good OO encapsulation avoids most problems with multithreding.
Developers of our services can use any tools they see fit to build their services.
I wonder how they avoid the maintenance nightmare which is having multiple application components done using various obscure technologies/tools and the person that did it leaving the company and somebody else having to maintain/extend those application components?
Do they standardize their build tools, require good documentation on the service implementations or just overwork the poor sods that have to do maintenance to death?
Eating cooked rice also helps stopping diarrhea. Normal rice, non genetic modifications whatsoever.
These simple old tricks come all the way from my grandmother, and i've used them often enough to know that they work (either that or it's the placebo effect in action).
This little discussion reminds me of a common scene in movies. It goes more or less like this:
- The hero of the story comes running into somebody's house, grabs some unexpected (and usually valued) object (say a valuable antique statue) and takes it way/throws it into the swimingpool/gets rid of it in some way - Everybody is surprised and shocked, maybe somebody even says "what the hell do you think you are doing?", and maybe even try to stop him. - Then that object explodes! (but thanks to our hero nobody gets hurt)
The thing is, in movies the audience knows beforehand WHY the hero is doing what he is doing, we've followed him through it and saw how he found out about the imminent danger. To us (audience), the shock, surprise and even attempts to stop the hero from getting rid of the dangerous object look stupid and misguided.
In a way AC/Paris is the hero here. By having a deeper understanding of how the world works he can beter see how a chain of events started by the actions of the current US administration risks going around the world and ending up making things worse for the american people instead of beter. By comparisson, those who cannot see further than their bellybuttons, who lack the mental ability to follow a chain of events further than 2 steps (action - reaction) and whose understanding of the world beyond their country can be summoned by "If you say something in english really loud to a non-english speaking foreigner they'll understand what you mean" just seem stupid and misguied.
In most of the recent Java Web-application servers all you have to do to re-deploy the Java code part of your web-application is "touch WEB-INF/web.xml" if you've deployed your web-app as a directory structure or place the newest WAR file in the deploy directory if your application is packaged in a WAR instead.
If your application is deployed as a directory structure then JSPs are hot deployed - all you have to do is replace the old JSP with the new one and the server will do the rest.
I think the reason why hosting of Java-based web-apps is rarer and more expensive than, say, PHP, has more to do with the bigger memory footprint of Java apps (especially due to the gazillions of 3rd party libs you need to use if you want to develop any serious application in an acceptable amount of time) and the comparative lack of experience with it within the Unix System Administrator community (Java web-apps have a longer and steeper learning curve than PHP) than with any lack of hot-deployability issues.
First a disclaimer: I've done AJAX, i've done JavaScript (and ECMAScript - ie outside a web-browser - too) for years now but i haven't done any Ruby and much less used RoR.
I can't believe you post is currently rated as +5 Insightful - it's a knee jerk, rant-like, fanboy reaction to the a criticism to your current "this is so cool" hype word du jour.
A couple of tasty snippets: The only part of that I'll give you is the poor IE implementation of CSS. Browsers' main problem lies in their non-compliance with standards. Solution: test in multiple browsers. WOW, THAT WAS HARD.
If having to test on every browser (not to mention browser versions) is not a mark of a poorly design technology i don't know what is.
Next up: JavaScript. Poor design? I was shocked at how powerful the language is when I finally started digging into it after years of avoidance. Poor imlpementation? Not really - just many different implementations. Of course, this can and has already been worked around with libs that abstract the differences away for you.
It's so well designed that people felt the need of doing many different implementations AND you need an abstraction layer on top of the language. Impressive.
HTML? It still is used as a basic markup language, with all the heavy lifting being pushed into the CSS. Now, CSS is nowhere near perfect, but it does function admirably in the scope of AJAX (when not using IE's broken ass implementation).
"nowhere near perfect, but it does function admirably in the scope of AJAX (when not using IE's broken ass implementation)"
So how exactly are you making your case here?
That sounds like marketroid speak, and is about 3/4ths BS. Perforate the abstraction layer? Jesus. And just who is running around writing C++ extensions for web apps? Almost nobody. Takes too damn long, and isn't as safe as running through the VM.
The OP mentioned it's "possible" to perforate the abstraction layer in the context of a framwork which (according to the article) achieves it's increase in developer productivity by being very specific of a certain type of situation. In response you went into a half-insulting rant that really doesn't show any logical or coherent arguments ("sounds like marketroid speak" and "who [...] Almost nobody" are not logical or coherent arguments)
Now for the real arguments: - AJAX is not a framework in any way at all. It is a natural evolution of DHTML (dynamic HTML, thus HTML, CSS and JavaScript) which adds asynchronous retrieving of data so that the displayed information can be asynchronously updated in specific locations (thus not the whole page) without having to use iframes. It's intended to solve a well known user interface problem with web-interfaces, which is that to users, (non-AJAX) web-interfaces feel slower and less responsive than GUI (thin/thick client) interfaces.
However AJAX does not in any way whatsover improve software development productivity - it actually is slower to implement most functionalities (functionality being something an application does for the users, not some piece of programming coolness) in AJAX than it is to implement it as full-page refresh in whatever server-side dynamic page generation language you are using.
A couple of reasons why software development productivity with AJAX is lower than with "traditional" approaches: - Comparative lack of frameworks/libraries that implement common functions in an AJAX compatible way. Meaning developers spend time reinventing the wheel while everybody else just creates new cars. - The platform on which AJAX runs (web-browser) is not properly standardized for some of the things which AJAX is heavy on (CSS, JavaScript), this meaning increased testing, increased amounts of "exceptional situations in the code" to "make this work with IE x.y" and increase duplication (with slight differences) of the code to have versions for multiple browsers. - JavaScript is a weak-typed language.
I'm all for it as long as long as both the surveilance information is available to all, and all have an equal likellyhood of being under surveilance at any moment.
More specifically it should be just as easy to catch a politician on camera as it should to catch anybody else, and said camera footage should be freely available to all.
This means that entrances/exits to places where politicians live/work should just as likelly be under the ever watching eye of a CCTV camera as those for everybody else AND that footage from those cameras should be just as easy to see by anybody as footage from any other CCTV cameras.
This includes number 10 Downing Street.
After all, honest politicians don't have anything to hide...
I suspect that due to "security reasons", it's way much harder to catch a politician (especially a member of the party in the government) on the "CCTV channel" (for example, when they have the money men of their constituency in as guests) than anybody else.
but software is different. if you're doing something the same way more than once, it's generally a warning sign that you could be doing it better somehow. following that to its logical conclusion, a good programmer will never do the exact same thing twice. meaning that, as a good programmer, you're always doing something you've never done before.
Strangelly enough i have two counter arguments at different levels:
1) Purelly in a programmer as coder sense, a good programmer will do the same thing EXACTLY twice. At that point said good programmer figures out he/she is doing duplicate code and moves that code to a separate method/class which gets called from both places.
2) At the higher, designer level, it's my experience that most software is composed of parts/features which are conceptually the same as those used in other, apparently unrelated applications. Things like persistent data storage (usually a db) and how to access it, configuration, error handling, administration user interfaces, user roles, validation of user input, interface adaptors and much more, are recurrent themes in most software. The small details vary but the patterns of how to do/use these things are most of the time the same. Because of this, design level solutions that work can be used over and over again - only the coding might be different, and even at code level, the commonalities can be detected and extracted to an external library/framework (for example a database access framework), and only the glue and situation specific code has to be (re)implemented.
The idea of always doing things anew because each time you know more than the last one is complete nonsense IMHO. To be a beter programmer it's much more important to be able to do more stuff and bigger stuff as seen from the point of view from the users/clients (ie software features, NOT lines of code) than it is to rewrite something from stratch in order to shave 2ms of generating a web-page to show to an user.
In my experience, rewriting something because of the gains you get from your increased experience is only worth it when you either have little experience or are doing something completly new for the second or third times.
When i'm discussing a request for implementing a new requirement or changing an existing requirement with the non-technical person making that request, a trick i usually do to show the complexity of apparently simple requests is to right there, present the high-level (eg. design) logical steps on how we would implement that request.
Non-technical people will understand the complexity of doing something when they follow you through the sketching of the process of making a solution that does it. For example, if you are asked to change a form so that a free text input field becomes a pull-down with a number of options you can: - Ask them if the list of options is fixed or if an application administrator can change them - If it's fixed, then it's easy to do, otherwise: - Explain that you have to store those options somewhere. Maybe you already have a database, so explain that you have to add storage tables to the database, then add code to the application so that it can load and save that information to and from memory. Also explain that you have to pre-load some sensible default values into the database so that the application works out of the box. - Since they want that some administrator can change it at runtime, figure out if said administrator is a developer/dba type of person or not. If not, explain that to allow an administrator user to change those values you have to extend your administrator interface, which means adding menu entries and one ore more new pages. - Also figure out what are the rules (if any) that constrain the values that the administrator can configure for the pull-down. Depending on the complexity of the rules you might want to follow through into how you would do it, for example, if the rules are based on other values in the database which can also be changed by an administrator: - Explain how you have to add code to retrieve and process the needed values so that you can check that the rules are not being broken, and that you also have to change the administrative interface for those other values so as to make sure that when they are changed or deleted, the values in the pull-down box do not become invalid. -...
The point here is that most non-technical people which actually use computers understand concepts such as memory and storing "data that cannot be lost when the application stops" (persistent data) somewhere other than memory. They can be made to understant the basics of a relational database: "a place to store data which has tables - a bit like excel tables - one table for each kind of information" (not exactly it but close enough) and they can usually follow a logical chain of steps (eg to show the data in the interface we have to get it from somewhere, since it is configurable, we store it in the place where we put the data that can be changed by the program but must be preserved even when the application stops).
Try and stay away of techie words and expressions ("We're gonna have to persist that data to our relational database and that means creating new tables, adding new data objects and changing the Hibernate mappings"). Instead assume non-techies are ignorant but not stupid ("We have to store that data in the database so that we don't loose it when the application stops. This means we have to configure in the database the tables where the data is stored and also have to add support in the program so that it can load that information into memory and use it").
Also, simplify: - Don't try to be overly exactly - for a non-techie is enough to say you have a "database" no need to say it's a "clustered configuration of a <insert-brand-here> relational database". - Don't go into deep details - you "configure the place in the database to store the data" no need to say you're "extending the tablespace, creating new tables, adding foreign keys to the related tables, and setting up a couple of indexes to speed up cross-referencing" - Try and tune your words to the audience - for some people you can say you're gon
Obviously this information is going to be used to track down subversive elements and their accomplices.
Thus members of environmentalist organisations, members of anti-war movements, members of anti-globalization movements, anybody that was a whistle-blowers of an illegal behaviour by a big corporation, anybody that's neither a registered Republican nor a registered Democrat and anybody that ever downloaded an MP3 from a P2P network.
Anybody that believes that State Surveilance organizations exist (be it in a "democratic" state or not) to protected the citizens instead of what they actual do which is defended the status quo and the existing power structures (also known as "protecting stability") can e-mail me 'cause i can sell you the location of my secret gold mine in the middle of the Atlantic.
In another study it has been found that women are very able at reading a man's williness to have sex from his face.
One participant in this study commented: "I just kept saying 'is willing' for each and every photo they showed me. In the end they told me i got every one of them right."
Another participant said that "this was just too easy" and that "the hanging drewling tongues and the eager looks or their [the men in the photos] faces where dead giveways".
Undisclousured sources told us of having overheard the main researcher on this study comment to his assistant that "this is our best scheme for getting girls phone numbers ever".
The management level corporate posture towards IT security goes like this: - We want to have our machines and network secure as long as it doesn't cause too much hassle to people and we don't pay a lot for it.
In other words, forget about big hardware changes, forget about changing the OS/E-mail client/Word editor/Web browser on the desktops of the staff, forget about getting all laptop users in their own sub-network and forget about retraining our staff to use computers in a way that helps improve our IT security. Oh, and by the way, if the CEO or some other VIP has some funky new program on his laptop that can't connect to the Net, just open those ports in the firewall.
And now IT Security professionals are to blame?
What's next? Maybe the cleaning lady at Enron was the one responsible for defrauding the investors????
Those that, when asked for help by collegues/clients, never say no and immediately go help that said collegue/client fix the problem, usually end up overworked with fixing stupid "problems" which the other person could've fixed himself (only its'easier to ask you).
It doesn't matter if your're sick, or if your life took a hard turn in the wrong direction latelly - once other people get used to coming to you for help fixing most kinds of problems they will just keep coming even if things aren't going well with you.
It's actually a very common human behaviour - people simply choose the easiest way out of their problems, and if the easiest way is by getting a friendly problem-fixer to solve it they will take that way almost everytime.
The way to solve this without actually saying "No!" is to make it so that you (friendly problem-fixer) are not the easiest path to getting problems fixed, except maybe for the real problems that nobody else can fix.
Essencially, you can use the following techniques: - make it more costly to get your help (in money and/or their time - after all, time is money) - provide them with the tools to solve their own problem and pressure them to use those tools before coming to you for help - provide them with an easier path to have their most common problems solved
Thus, for example if you're a contractor you could: - Make/increase the cost of getting you to give support. - Make people jump through a couple of hoops to get your help - for example the above mentioned "bring your computer to my place and i'll fix it" method - Provide customers with instructions on how to fix common problems (ie documentation, such as a mini-FAQ). If they still bring these problems to you, remind them that they have instructons on how to solve it, delay fixing the problem for a while and them come back to them and ask them if they still have the problem - they'le probably fix it themselfs. - Provide customers with the contact of a company that can help them solve the more basic computer problems.
Similarly, if working within a company you can: - ask them to go to your manager to reserve some of your time to solved their problem and/or book that time in their budget. - make them jump through hoops to get your help - for example, requiring a complete description of the problem in an e-mail before you move a muscle to help them - teach them how to fix it the first time the problem happens and next time insist that they try it themselfs first (and just to make the message clear, delay giving direct help) - tell them to go to the "whatever" (Systems/Database/...) Administration department 'cause "they can fix it for you".
"The real determiners of the HD format wars will be the adult DVD producers."
Conventional wisdom is that adult DVD doesn't want high definition, as the 480-line output of standard definition production hides the imperfections in erotic actors' skin.
Which dovetails very nicelly with the theory that the winner of the HD format wars will be the plain old standard DVD - in other words, both HD-DVD and Blueray will end up the same way as SACD and DVD-Audio
Could it be that the Atari is simpler in design and less prone to breaking whereas the PS2 is much more complex and has notably more points of failure?
Nowadays, at least in the electronics world, there is a much smaller number of discrete components in an electronic circuit than just 10 years ago.
Basically a lot of the functionality which before was implemented by multiple basic integrated circuits spread all over the circuit board has been move into specialized integrated circuits.
In the area of computers, circuit boards nowadays have more pathways (esp. because of the widers buses, often 128 bit instead of 8 or even 4 bit) but less contacts (even though current integrated circuits have more contacts, there are a lot less discrete components now).
Just compare a PC motherboard from 10 years ago with a current one if you want an example of that.
Thus increased complexity doesn't seem to be the problem - the increase in complexity has happened inside integrated circuits which are much less prone to mechanical failures than circuit boards. Modern ICs are more prone to heat induced failures and the cheap ones also can't survive voltage spikes very well.
More likelly it's the cheap power sources that can't take extreme spikes in the power from the electric grid (which in all honestly if much noisier than the expected 50-60 cycles sinousoidal wave), the cheap heat dissipation arranjements for the hottest ICs and the low quality plastic controlers mass produced to last + 1 day.
In their infinite wisdom management has decided that, since programmers now know how to program safelly, programmers will have the responsability of avoiding security bugs while still having to deliver the application withing the same deadline.
Believe me when I say that implementing CALEA in VOIP isn't trivial since the data must be intercepted somewhere.
Simple, all non-open source VOIP implementations have to include an IRC control console which connects to a specific, password protected IRC channel in Undernet and waits for commands from a human controller, for example "redirect [ip-address]"
As an added bonus they can have the "ddos [ip-adress]" command and aknowledge reception of any command by saying "Yes, master!".
Europe has much better environmental and consumer protection laws and regulations than the US.
Consumer protection is especially stringent in the area of food.
Thus, in Europe, substances whose long-term effects are now well known are usually forbidden in the food chain.
These kind of regulations affect not only processed food but also things like how farm animals destined for human consumption or which make food products such as eggs or milk are bred.
Thus for example, use of growth hormones in cattle is forbiden and the kinds and amounts of additives that can be added to processed food are highly regulated.
Similarly, environmental regulations are stricter in Europe, and things like car emissions are very thightly controlled all across Europe.
My personal pet theory is that this kind of regulations in Europe has decreased the incidence of the health problems related with long term exposure to chemicals which, unknowingly to the science community, cause those health problems which, such as cancer, are very difficult to track back to their source.
In other words, food and air around here are less likelly to make us sick in the long term.
I reckon that this is another important factor in explaining the difference in health between Americans and British.
if all the good guys did turn contractor overnight, and suddenly charge what they were actually worth to the company rather than what was offered when they signed up, but for now, the "market forces" make this unlikely.
This is actually what seems to be happening in Holland at the moment, at least for senior software designer/developer positions.
About 3 months ago, all of the sudden most companies decided the worst (of the recession) was over and that they really needed to do those software upgrades/implementations they had been postponing for the last 3 years.
At the same time, the big consultancies started big hiring drives...
This cleared up the few available people for permanent positions really fast, at which point both the consultancies and any companies doing implementations started going for contractors since they couldn't find permanent employees.
In short order, both the permanent and the contracting market were red hot.
Meanwhile, the enormous amount of work available meant that just about all small consultancies around here had more work than people to do it with. Since they couldn't find enough senior persons in the permanent market, they had to go for contractors... which made that market even hotter.
At this point, the word that the market was good had filtered down to job search web-sites and anybody that tought that they could make a job placement agency... resulting in TV ad-campaigns from the likes of Monsterboard and an almost overnight increase in the number of job agencies by a factor or 3 or more - all of them trying to convince people to change jobs.
At this point, employees started waking up and changing jobs:)
The interesting part is that many, after seeing during the recession exactly how much most companies really care about their employees (as in hearing in the news about downsizings, seeing collegues and friends being downsized and, in some cases, being downsized themselfs) have decided to move from being a permanent to being contractors, especially those with good qualifications (read senior people with good CVs) - after all, if in practice the job security in permanent positions is an illusion (which in Holland, with the current laws, it is), earning as a contractor 3x as much as you make as a permanent is a good alternative way of guaranteeing financial security.
So yeah, at this point people are jumping jobs and, especially the good ones, are becoming contractors.
Did i mention that there's a lack of qualified senior developers around here a.t.m., even contractors? - Its a great time to be a contractor around here:)))
Did i mention contractors mostly have multiple months, 8h/day contracts while being payed by the hour around here? Trust me, when being payed by the hour overwork is really rare;)
Actually, from my own personal experience of having worked as a software developer both in 10h/day (2h unpaid) jobs and 8h/day ones (different countries), after about a month of continuous working 10h/day your total dailly productivity (in those 10h) is actually lower than would be (in an 8h working day) under an 8h/day regime.
Even more important is the fact that tired people make a lot more bugs than rested ones, and bugfixing can easilly be 10 or 100 (or even 1000 or 10000 if the software gets released with the bugs) times more costly to do than doing the work right in the first place.
Of course, the project might still have been released on time with the help of overworking... only to stall for months in beta testing, be rejected by clients which are not interested in buggy software or have a long tail-period where bugs are being reported and bugfixes are constantly being developed and released to the customers.
From what i've seen, overworking prospers mostly in companies with clueless middle-management or industries with clueless clients (which are used to buggy and/or incomplete deliverables) and where developers are mostly young, male and single (easiest ones to convince that "this is the normal way of doing things").
we have already spent trying to figure out why, oh, why java croaks on OutOfMemoryException when we have more than 8G of ram most of which is not being used.
a) The Sun JVM will not use all available memory unless instructed to do so. You can give it a start parameter to set it's maximum used memory to a value other than the default (which is 512M i believe) b) It's perfectly possible to have memory leaks in Java. Basically as long as a reference to an Object is still being hold by a "live" Object, then it, plus all the other Objects it references will not be garbage collected. Things like registering API Objects as Observers/Listeners in allways-in-memory model objects and then not unregistering them when you don't need them anymore (even though you've closed the window or such) are a great way of getting memory leaks.
Been doing Java for as long as you and haven't reached the same conclusion as you did. This is probably because the other languages i have worked with (C, C++, PHP to name just a few) have shown themselfs to, in the hands of average/below-average programmers, be more prone to result in hard-to-maintain/bug-prone code that Java is. Since 50% of software developers are below-average, that single characteristic saves me and others like me (senior designer/developer, problem-solver) a lot of time and stress.
I can see it now, little Billy, without their parents knowing about it, makes a small rocket out of firecrackers and matchheads. He takes it ouside to try it out and immediatly gets stopped by an army of patent lawyers armed with patents on any and all details of rockets, for example "a means of accelerating an object in a direction by ejecting gases at high-speed in the opposite direction", thus saving little Billy of the disapointment of seing that is rocket actually doesn't work or even from bodilly harm if the rocket exploded.
In other news, patent lawyers armed with patents on all forms of causing bodilly harm are reducing terrorism!!!
Slashdot Mirror
From somebody that DID do C & C++ and has been doing mostly Java for a number of years now:
- Get an experienced Java Developer/Designer/Architect inhouse at least for preparing and doing the migration. Put that person in a team-lead/team-coach role or at the very least use him/her for high-level design and for code reviewings. No mater how good you guys are, when you move to a different language AND more importantly a new set of libraries and frameworks, if you do it on your own you're going to make all the mistakes a "new guy" does which means a lot of going back and forward as you figure out that your initial design doesn't quite work with Hibernate/Spring/J2EE/whatever.
- Develop a couple of some small apps first, just to get some experience with the language itself - take a week or two doing it. Try and use the libraries/frameworks you wanna use in the main project - for example, if you wanna use Hibernate to access the database, do a small app that works with it.
- If some of you guys are still using non-object oriented features from the C side of C++, you're going to have problems moving to Java. The simplest solution is using loads of static methods in an auxiliary class. DON'T! Generic auxiliary methods in Java are the exception, not the rule in most applications.
- Beware of thread safety. Multi-threading is a built-in feature in the standard Java libraries, and when using some of the major frameworks (J2EE for example, both the web side and EJBs) or having to deal with asynchronous events from multiple external entities (for example the server-side of a multiple-user client-server app) it is almost guarante that some of your methods WILL BE called by multiple threads simultaneously. If you make auxiliary methods at the class level (or worse, in a generic class), beware of them keeping state - in a multi-threaded environment there is no guarantee that said methods will be called in any given order, even if the your code looks like it will never do otherwise. The only way to control multi-threaded access to resources that have state is to either not share them (ie put the auxiliary methods in an object or encapsulate state in an object that gets passed to the methods) or carefully using synchronized blocks and methods (very few people know how to do the last one properly). Fortunatly, good OO encapsulation avoids most problems with multithreding.
Developers of our services can use any tools they see fit to build their services.
I wonder how they avoid the maintenance nightmare which is having multiple application components done using various obscure technologies/tools and the person that did it leaving the company and somebody else having to maintain/extend those application components?
Do they standardize their build tools, require good documentation on the service implementations or just overwork the poor sods that have to do maintenance to death?
Eat uncooked flour dissolved in a little water.
Eating cooked rice also helps stopping diarrhea. Normal rice, non genetic modifications whatsoever.
These simple old tricks come all the way from my grandmother, and i've used them often enough to know that they work (either that or it's the placebo effect in action).
So why exactly do we need frankein-rice for?
This little discussion reminds me of a common scene in movies. It goes more or less like this:
- The hero of the story comes running into somebody's house, grabs some unexpected (and usually valued) object (say a valuable antique statue) and takes it way/throws it into the swimingpool/gets rid of it in some way
- Everybody is surprised and shocked, maybe somebody even says "what the hell do you think you are doing?", and maybe even try to stop him.
- Then that object explodes! (but thanks to our hero nobody gets hurt)
The thing is, in movies the audience knows beforehand WHY the hero is doing what he is doing, we've followed him through it and saw how he found out about the imminent danger. To us (audience), the shock, surprise and even attempts to stop the hero from getting rid of the dangerous object look stupid and misguided.
In a way AC/Paris is the hero here. By having a deeper understanding of how the world works he can beter see how a chain of events started by the actions of the current US administration risks going around the world and ending up making things worse for the american people instead of beter.
By comparisson, those who cannot see further than their bellybuttons, who lack the mental ability to follow a chain of events further than 2 steps (action - reaction) and whose understanding of the world beyond their country can be summoned by "If you say something in english really loud to a non-english speaking foreigner they'll understand what you mean" just seem stupid and misguied.
In most of the recent Java Web-application servers all you have to do to re-deploy the Java code part of your web-application is "touch WEB-INF/web.xml" if you've deployed your web-app as a directory structure or place the newest WAR file in the deploy directory if your application is packaged in a WAR instead.
If your application is deployed as a directory structure then JSPs are hot deployed - all you have to do is replace the old JSP with the new one and the server will do the rest.
I think the reason why hosting of Java-based web-apps is rarer and more expensive than, say, PHP, has more to do with the bigger memory footprint of Java apps (especially due to the gazillions of 3rd party libs you need to use if you want to develop any serious application in an acceptable amount of time) and the comparative lack of experience with it within the Unix System Administrator community (Java web-apps have a longer and steeper learning curve than PHP) than with any lack of hot-deployability issues.
First a disclaimer: I've done AJAX, i've done JavaScript (and ECMAScript - ie outside a web-browser - too) for years now but i haven't done any Ruby and much less used RoR.
I can't believe you post is currently rated as +5 Insightful - it's a knee jerk, rant-like, fanboy reaction to the a criticism to your current "this is so cool" hype word du jour.
A couple of tasty snippets:
The only part of that I'll give you is the poor IE implementation of CSS. Browsers' main problem lies in their non-compliance with standards. Solution: test in multiple browsers. WOW, THAT WAS HARD.
If having to test on every browser (not to mention browser versions) is not a mark of a poorly design technology i don't know what is.
Next up: JavaScript. Poor design? I was shocked at how powerful the language is when I finally started digging into it after years of avoidance. Poor imlpementation? Not really - just many different implementations. Of course, this can and has already been worked around with libs that abstract the differences away for you.
It's so well designed that people felt the need of doing many different implementations AND you need an abstraction layer on top of the language. Impressive.
HTML? It still is used as a basic markup language, with all the heavy lifting being pushed into the CSS. Now, CSS is nowhere near perfect, but it does function admirably in the scope of AJAX (when not using IE's broken ass implementation).
"nowhere near perfect, but it does function admirably in the scope of AJAX (when not using IE's broken ass implementation)"
So how exactly are you making your case here?
That sounds like marketroid speak, and is about 3/4ths BS. Perforate the abstraction layer? Jesus. And just who is running around writing C++ extensions for web apps? Almost nobody. Takes too damn long, and isn't as safe as running through the VM.
The OP mentioned it's "possible" to perforate the abstraction layer in the context of a framwork which (according to the article) achieves it's increase in developer productivity by being very specific of a certain type of situation.
In response you went into a half-insulting rant that really doesn't show any logical or coherent arguments ("sounds like marketroid speak" and "who [...] Almost nobody" are not logical or coherent arguments)
Now for the real arguments:
- AJAX is not a framework in any way at all. It is a natural evolution of DHTML (dynamic HTML, thus HTML, CSS and JavaScript) which adds asynchronous retrieving of data so that the displayed information can be asynchronously updated in specific locations (thus not the whole page) without having to use iframes.
It's intended to solve a well known user interface problem with web-interfaces, which is that to users, (non-AJAX) web-interfaces feel slower and less responsive than GUI (thin/thick client) interfaces.
However AJAX does not in any way whatsover improve software development productivity - it actually is slower to implement most functionalities (functionality being something an application does for the users, not some piece of programming coolness) in AJAX than it is to implement it as full-page refresh in whatever server-side dynamic page generation language you are using.
A couple of reasons why software development productivity with AJAX is lower than with "traditional" approaches:
- Comparative lack of frameworks/libraries that implement common functions in an AJAX compatible way. Meaning developers spend time reinventing the wheel while everybody else just creates new cars.
- The platform on which AJAX runs (web-browser) is not properly standardized for some of the things which AJAX is heavy on (CSS, JavaScript), this meaning increased testing, increased amounts of "exceptional situations in the code" to "make this work with IE x.y" and increase duplication (with slight differences) of the code to have versions for multiple browsers.
- JavaScript is a weak-typed language.
I'm all for it as long as long as both the surveilance information is available to all, and all have an equal likellyhood of being under surveilance at any moment.
...
More specifically it should be just as easy to catch a politician on camera as it should to catch anybody else, and said camera footage should be freely available to all.
This means that entrances/exits to places where politicians live/work should just as likelly be under the ever watching eye of a CCTV camera as those for everybody else AND that footage from those cameras should be just as easy to see by anybody as footage from any other CCTV cameras.
This includes number 10 Downing Street.
After all, honest politicians don't have anything to hide
I suspect that due to "security reasons", it's way much harder to catch a politician (especially a member of the party in the government) on the "CCTV channel" (for example, when they have the money men of their constituency in as guests) than anybody else.
but software is different. if you're doing something the same way more than once, it's generally a warning sign that you could be doing it better somehow. following that to its logical conclusion, a good programmer will never do the exact same thing twice. meaning that, as a good programmer, you're always doing something you've never done before.
Strangelly enough i have two counter arguments at different levels:
1) Purelly in a programmer as coder sense, a good programmer will do the same thing EXACTLY twice. At that point said good programmer figures out he/she is doing duplicate code and moves that code to a separate method/class which gets called from both places.
2) At the higher, designer level, it's my experience that most software is composed of parts/features which are conceptually the same as those used in other, apparently unrelated applications. Things like persistent data storage (usually a db) and how to access it, configuration, error handling, administration user interfaces, user roles, validation of user input, interface adaptors and much more, are recurrent themes in most software. The small details vary but the patterns of how to do/use these things are most of the time the same.
Because of this, design level solutions that work can be used over and over again - only the coding might be different, and even at code level, the commonalities can be detected and extracted to an external library/framework (for example a database access framework), and only the glue and situation specific code has to be (re)implemented.
The idea of always doing things anew because each time you know more than the last one is complete nonsense IMHO. To be a beter programmer it's much more important to be able to do more stuff and bigger stuff as seen from the point of view from the users/clients (ie software features, NOT lines of code) than it is to rewrite something from stratch in order to shave 2ms of generating a web-page to show to an user.
In my experience, rewriting something because of the gains you get from your increased experience is only worth it when you either have little experience or are doing something completly new for the second or third times.
When i'm discussing a request for implementing a new requirement or changing an existing requirement with the non-technical person making that request, a trick i usually do to show the complexity of apparently simple requests is to right there, present the high-level (eg. design) logical steps on how we would implement that request.
...
Non-technical people will understand the complexity of doing something when they follow you through the sketching of the process of making a solution that does it. For example, if you are asked to change a form so that a free text input field becomes a pull-down with a number of options you can:
- Ask them if the list of options is fixed or if an application administrator can change them
- If it's fixed, then it's easy to do, otherwise:
- Explain that you have to store those options somewhere. Maybe you already have a database, so explain that you have to add storage tables to the database, then add code to the application so that it can load and save that information to and from memory. Also explain that you have to pre-load some sensible default values into the database so that the application works out of the box.
- Since they want that some administrator can change it at runtime, figure out if said administrator is a developer/dba type of person or not. If not, explain that to allow an administrator user to change those values you have to extend your administrator interface, which means adding menu entries and one ore more new pages.
- Also figure out what are the rules (if any) that constrain the values that the administrator can configure for the pull-down. Depending on the complexity of the rules you might want to follow through into how you would do it, for example, if the rules are based on other values in the database which can also be changed by an administrator:
- Explain how you have to add code to retrieve and process the needed values so that you can check that the rules are not being broken, and that you also have to change the administrative interface for those other values so as to make sure that when they are changed or deleted, the values in the pull-down box do not become invalid.
-
The point here is that most non-technical people which actually use computers understand concepts such as memory and storing "data that cannot be lost when the application stops" (persistent data) somewhere other than memory. They can be made to understant the basics of a relational database: "a place to store data which has tables - a bit like excel tables - one table for each kind of information" (not exactly it but close enough) and they can usually follow a logical chain of steps (eg to show the data in the interface we have to get it from somewhere, since it is configurable, we store it in the place where we put the data that can be changed by the program but must be preserved even when the application stops).
Try and stay away of techie words and expressions ("We're gonna have to persist that data to our relational database and that means creating new tables, adding new data objects and changing the Hibernate mappings"). Instead assume non-techies are ignorant but not stupid ("We have to store that data in the database so that we don't loose it when the application stops. This means we have to configure in the database the tables where the data is stored and also have to add support in the program so that it can load that information into memory and use it").
Also, simplify:
- Don't try to be overly exactly - for a non-techie is enough to say you have a "database" no need to say it's a "clustered configuration of a <insert-brand-here> relational database".
- Don't go into deep details - you "configure the place in the database to store the data" no need to say you're "extending the tablespace, creating new tables, adding foreign keys to the related tables, and setting up a couple of indexes to speed up cross-referencing"
- Try and tune your words to the audience - for some people you can say you're gon
Obviously this information is going to be used to track down subversive elements and their accomplices.
Thus members of environmentalist organisations, members of anti-war movements, members of anti-globalization movements, anybody that was a whistle-blowers of an illegal behaviour by a big corporation, anybody that's neither a registered Republican nor a registered Democrat and anybody that ever downloaded an MP3 from a P2P network.
Anybody that believes that State Surveilance organizations exist (be it in a "democratic" state or not) to protected the citizens instead of what they actual do which is defended the status quo and the existing power structures (also known as "protecting stability") can e-mail me 'cause i can sell you the location of my secret gold mine in the middle of the Atlantic.
In another study it has been found that women are very able at reading a man's williness to have sex from his face.
One participant in this study commented: "I just kept saying 'is willing' for each and every photo they showed me. In the end they told me i got every one of them right."
Another participant said that "this was just too easy" and that "the hanging drewling tongues and the eager looks or their [the men in the photos] faces where dead giveways".
Undisclousured sources told us of having overheard the main researcher on this study comment to his assistant that "this is our best scheme for getting girls phone numbers ever".
The management level corporate posture towards IT security goes like this:
- We want to have our machines and network secure as long as it doesn't cause too much hassle to people and we don't pay a lot for it.
In other words, forget about big hardware changes, forget about changing the OS/E-mail client/Word editor/Web browser on the desktops of the staff, forget about getting all laptop users in their own sub-network and forget about retraining our staff to use computers in a way that helps improve our IT security. Oh, and by the way, if the CEO or some other VIP has some funky new program on his laptop that can't connect to the Net, just open those ports in the firewall.
And now IT Security professionals are to blame?
What's next? Maybe the cleaning lady at Enron was the one responsible for defrauding the investors????
Those that, when asked for help by collegues/clients, never say no and immediately go help that said collegue/client fix the problem, usually end up overworked with fixing stupid "problems" which the other person could've fixed himself (only its'easier to ask you).
It doesn't matter if your're sick, or if your life took a hard turn in the wrong direction latelly - once other people get used to coming to you for help fixing most kinds of problems they will just keep coming even if things aren't going well with you.
It's actually a very common human behaviour - people simply choose the easiest way out of their problems, and if the easiest way is by getting a friendly problem-fixer to solve it they will take that way almost everytime.
The way to solve this without actually saying "No!" is to make it so that you (friendly problem-fixer) are not the easiest path to getting problems fixed, except maybe for the real problems that nobody else can fix.
Essencially, you can use the following techniques:
- make it more costly to get your help (in money and/or their time - after all, time is money)
- provide them with the tools to solve their own problem and pressure them to use those tools before coming to you for help
- provide them with an easier path to have their most common problems solved
Thus, for example if you're a contractor you could:
- Make/increase the cost of getting you to give support.
- Make people jump through a couple of hoops to get your help - for example the above mentioned "bring your computer to my place and i'll fix it" method
- Provide customers with instructions on how to fix common problems (ie documentation, such as a mini-FAQ). If they still bring these problems to you, remind them that they have instructons on how to solve it, delay fixing the problem for a while and them come back to them and ask them if they still have the problem - they'le probably fix it themselfs.
- Provide customers with the contact of a company that can help them solve the more basic computer problems.
Similarly, if working within a company you can:
- ask them to go to your manager to reserve some of your time to solved their problem and/or book that time in their budget.
- make them jump through hoops to get your help - for example, requiring a complete description of the problem in an e-mail before you move a muscle to help them
- teach them how to fix it the first time the problem happens and next time insist that they try it themselfs first (and just to make the message clear, delay giving direct help)
- tell them to go to the "whatever" (Systems/Database/...) Administration department 'cause "they can fix it for you".
"The real determiners of the HD format wars will be the adult DVD producers."
Conventional wisdom is that adult DVD doesn't want high definition, as the 480-line output of standard definition production hides the imperfections in erotic actors' skin.
Which dovetails very nicelly with the theory that the winner of the HD format wars will be the plain old standard DVD - in other words, both HD-DVD and Blueray will end up the same way as SACD and DVD-Audio
Could it be that the Atari is simpler in design and less prone to breaking whereas the PS2 is much more complex and has notably more points of failure?
Nowadays, at least in the electronics world, there is a much smaller number of discrete components in an electronic circuit than just 10 years ago.
Basically a lot of the functionality which before was implemented by multiple basic integrated circuits spread all over the circuit board has been move into specialized integrated circuits.
In the area of computers, circuit boards nowadays have more pathways (esp. because of the widers buses, often 128 bit instead of 8 or even 4 bit) but less contacts (even though current integrated circuits have more contacts, there are a lot less discrete components now).
Just compare a PC motherboard from 10 years ago with a current one if you want an example of that.
Thus increased complexity doesn't seem to be the problem - the increase in complexity has happened inside integrated circuits which are much less prone to mechanical failures than circuit boards. Modern ICs are more prone to heat induced failures and the cheap ones also can't survive voltage spikes very well.
More likelly it's the cheap power sources that can't take extreme spikes in the power from the electric grid (which in all honestly if much noisier than the expected 50-60 cycles sinousoidal wave), the cheap heat dissipation arranjements for the hottest ICs and the low quality plastic controlers mass produced to last + 1 day.
I was aiming for a Captain America effect you insensitive clod ;)
Aceticon's list of /. heroes and villains:
Heroes:
- First Poster
- Insightfull Man
- Super Funny
- Anonymous Coward
- Cmdr Taco
Villains:
- Grammar Nazi
- Insensitive Clod
- Mega Troll
- Anonymous Coward's Evil Twin
In their infinite wisdom management has decided that, since programmers now know how to program safelly, programmers will have the responsability of avoiding security bugs while still having to deliver the application withing the same deadline.
Believe me when I say that implementing CALEA in VOIP isn't trivial since the data must be intercepted somewhere.
Simple, all non-open source VOIP implementations have to include an IRC control console which connects to a specific, password protected IRC channel in Undernet and waits for commands from a human controller, for example "redirect [ip-address]"
As an added bonus they can have the "ddos [ip-adress]" command and aknowledge reception of any command by saying "Yes, master!".
"360 Shadowrun Title Partially Confirmed" - according to reliable sources in the industry the word "Shadowrun" will be part of the title.
In other news "Color of Napoleon's white horse partially confirmed as being white"
Europe has much better environmental and consumer protection laws and regulations than the US.
Consumer protection is especially stringent in the area of food.
Thus, in Europe, substances whose long-term effects are now well known are usually forbidden in the food chain.
These kind of regulations affect not only processed food but also things like how farm animals destined for human consumption or which make food products such as eggs or milk are bred.
Thus for example, use of growth hormones in cattle is forbiden and the kinds and amounts of additives that can be added to processed food are highly regulated.
Similarly, environmental regulations are stricter in Europe, and things like car emissions are very thightly controlled all across Europe.
My personal pet theory is that this kind of regulations in Europe has decreased the incidence of the health problems related with long term exposure to chemicals which, unknowingly to the science community, cause those health problems which, such as cancer, are very difficult to track back to their source.
In other words, food and air around here are less likelly to make us sick in the long term.
I reckon that this is another important factor in explaining the difference in health between Americans and British.
if all the good guys did turn contractor overnight, and suddenly charge what they were actually worth to the company rather than what was offered when they signed up, but for now, the "market forces" make this unlikely.
...
... which made that market even hotter.
... resulting in TV ad-campaigns from the likes of Monsterboard and an almost overnight increase in the number of job agencies by a factor or 3 or more -
:)
:)))
;)
This is actually what seems to be happening in Holland at the moment, at least for senior software designer/developer positions.
About 3 months ago, all of the sudden most companies decided the worst (of the recession) was over and that they really needed to do those software upgrades/implementations they had been postponing for the last 3 years.
At the same time, the big consultancies started big hiring drives
This cleared up the few available people for permanent positions really fast, at which point both the consultancies and any companies doing implementations started going for contractors since they couldn't find permanent employees.
In short order, both the permanent and the contracting market were red hot.
Meanwhile, the enormous amount of work available meant that just about all small consultancies around here had more work than people to do it with. Since they couldn't find enough senior persons in the permanent market, they had to go for contractors
At this point, the word that the market was good had filtered down to job search web-sites and anybody that tought that they could make a job placement agency
all of them trying to convince people to change jobs.
At this point, employees started waking up and changing jobs
The interesting part is that many, after seeing during the recession exactly how much most companies really care about their employees (as in hearing in the news about downsizings, seeing collegues and friends being downsized and, in some cases, being downsized themselfs) have decided to move from being a permanent to being contractors, especially those with good qualifications (read senior people with good CVs) - after all, if in practice the job security in permanent positions is an illusion (which in Holland, with the current laws, it is), earning as a contractor 3x as much as you make as a permanent is a good alternative way of guaranteeing financial security.
So yeah, at this point people are jumping jobs and, especially the good ones, are becoming contractors.
Did i mention that there's a lack of qualified senior developers around here a.t.m., even contractors? - Its a great time to be a contractor around here
Did i mention contractors mostly have multiple months, 8h/day contracts while being payed by the hour around here? Trust me, when being payed by the hour overwork is really rare
Actually, from my own personal experience of having worked as a software developer both in 10h/day (2h unpaid) jobs and 8h/day ones (different countries), after about a month of continuous working 10h/day your total dailly productivity (in those 10h) is actually lower than would be (in an 8h working day) under an 8h/day regime.
... only to stall for months in beta testing, be rejected by clients which are not interested in buggy software or have a long tail-period where bugs are being reported and bugfixes are constantly being developed and released to the customers.
Even more important is the fact that tired people make a lot more bugs than rested ones, and bugfixing can easilly be 10 or 100 (or even 1000 or 10000 if the software gets released with the bugs) times more costly to do than doing the work right in the first place.
Of course, the project might still have been released on time with the help of overworking
From what i've seen, overworking prospers mostly in companies with clueless middle-management or industries with clueless clients (which are used to buggy and/or incomplete deliverables) and where developers are mostly young, male and single (easiest ones to convince that "this is the normal way of doing things").
we have already spent trying to figure out why, oh, why java croaks on OutOfMemoryException when we have more than 8G of ram most of which is not being used.
a) The Sun JVM will not use all available memory unless instructed to do so. You can give it a start parameter to set it's maximum used memory to a value other than the default (which is 512M i believe)
b) It's perfectly possible to have memory leaks in Java. Basically as long as a reference to an Object is still being hold by a "live" Object, then it, plus all the other Objects it references will not be garbage collected. Things like registering API Objects as Observers/Listeners in allways-in-memory model objects and then not unregistering them when you don't need them anymore (even though you've closed the window or such) are a great way of getting memory leaks.
Been doing Java for as long as you and haven't reached the same conclusion as you did. This is probably because the other languages i have worked with (C, C++, PHP to name just a few) have shown themselfs to, in the hands of average/below-average programmers, be more prone to result in hard-to-maintain/bug-prone code that Java is. Since 50% of software developers are below-average, that single characteristic saves me and others like me (senior designer/developer, problem-solver) a lot of time and stress.
I can see it now, little Billy, without their parents knowing about it, makes a small rocket out of firecrackers and matchheads. He takes it ouside to try it out and immediatly gets stopped by an army of patent lawyers armed with patents on any and all details of rockets, for example "a means of accelerating an object in a direction by ejecting gases at high-speed in the opposite direction", thus saving little Billy of the disapointment of seing that is rocket actually doesn't work or even from bodilly harm if the rocket exploded.
In other news, patent lawyers armed with patents on all forms of causing bodilly harm are reducing terrorism!!!