Oh no, don't get me wrong - I understand the interpersonal issues involved in such a thing, but then I have also worked on government IT and understand the stupid "it says in the contract" where you cannot deviate from what they wanted even if you and your immediate contact agree it needs to be changed!
I was just suggesting that, with the lack of effective leadership a code monkey has to do what he's told, and cannot realistically make it work without backing from someone who should be providing the kind of leadership that creates and manages the relationship with the customer.
In my example, I built the relationship myself as no-one was happy with the situation. In other circumstances, I may not have that opportunity and then I'll have to do what I'm told regardless.
I find the ones who rush to use the new stuff are the ones who never quite managed to make anything with the old ones. The grass is always greener but also they can blame their lack of progress on the tools.. obviously *this* time it'll be different, just once they've had the right training and given enough time.....
Its when I was offered a job to make a system cope with the customer's increased load that I realised how damaging this is - it was written in Erlang, Ruby and Scala.
Or because some people can't cope with another variation on C++.
They're just tools guys, all these languages coming out, its just like making slightly different style hammers, only hammers don't need any training or lengthy experience to develop decent skills to use.
In such cases you take the requirements document and fulfill it exactly. Then , when the customer says "but its broke and doesn't do.." you pull out the requirements and say "it does everything you asked us to do, anything further is additional development and will be billed accordingly".
Why else do you think government IT contracts cost so much? Why else do you think Agile was invented?
The core problem is that the customer doesn't know how to achieve successful delivery, they need to be educated in fundamental agile processes, of iterative development to evolving requirements (and by evolve, I mean "as the customer figures out what they want".
I used to have similar problems with a customer, but fortunately I had a contact who knew the business. When I received the stupid requirements, I'd phone him and ask what they really meant. Then I'd develop what he said and deliver it to the customer who was always happy, not matter how far from the written spec it was (it helped that my contact was a senior guy at the customer or it wouldn't have worked)
You work on technology X for a while, you learn it inside and out, and you expect everyone else who is "qualified" knows what you know. but they moved on from that technology a couple of years ago and now only want to develop in Java/Erlang/Ruby/Node/Scala (* delete as applicable as depending on which year this decade you were hiring).
even more mature technologies like.NET are stuffed full of so much churn that no-one really has time to become a master of any of it. Like my mate who was brought into a ASP.NET shop, he learned their tech stack, then one day noticed the trunk had changed a lot, so went to ask the architects who said "oh yes, we decided to move forward with our DB tech, so we're using a repository pattern now". So he goes and learns all about that, does some work on a branch, then goes to merge and... its all changed again. So goes to see the architects who say "ooh no, we decided repository pattern wasn't good enough so we've changed to using entity framework". Now that shop was just stupid, but to a lesser extent this is what is happening all over the industry.
Whilst I agree that change is necessary to keep things progressing, we're almost in a throwaway culture in ITT where everything we ever did is not good enough and has to be replaced. While there are forces pushing against this (for example, all the people who want to do the big rewrite now know its a bad idea) we still have change via refactoring and flavour-of-the-month tech patterns and frameworks pushed at us.
Only when the industry gets the idea that stable is a good thing and making products is what we should be focussed on doing (ie not changing tech all the time) will this industry be as good career as the other engineering professions.
Then lie. If anyone asks, you just say "oh that, I put it on to prevent identity theft, anyone claiming to be me would not have provably correct information, I always send my correct CV to employers if I apply for a job", leaving out the implicit "fool you for looking at shit on the internet and assuming it was always true".
Now they have flipped it so you get a credit back if you get a response.
Hmm.. so now I'm wondering if its better to keep ignoring those crappy job emails I keep getting to cost the recruiters when they spam me, or to respond to them to stop LinkedIn gaining revenue from my presence.
Mostly pointless though, full encryption for data comms is often worthless - who cares about encrypted comms if all you're doing is looking at pictures of cats. When you're posting subversion messages criticising your local dictator, you need something better than plain old encryption anyway.
Now working with certificate authorities to manage revoked certificates is a good thing, but many of the problems with CAs are a more human problem - until we get to a point where encryption is seen as different to authentication (and even then, my comms with my bank might be encrypted but I need to know that it is my bank I'm talking to as well) and that the CA correctly handed that certificate to my bank, and not some scammer pretending to be my bank. And allowing my bank to verify that it is me that is sending them requests and not some identity thief.
The point I'm trying to make is that encryption isn't the problem that need to be solved, it all the infrastructure around it that does. Mandatory encryption isn't any solution to anything useful.
I think you're confusing the protocol verbs with a heap of javabollocks on the back end.
In most systems GET occurs much more often than POST, and if you're returning to a system after logging off, you'll be doing a lot of GETs just to restore your environment (or page view).
I think a POST+GET optimisation would be nice, but it would be an optimisation, a little like how some DBs have a 'insert, or update if already exists' statement. But you can already return data from a POST, it does break the concept but it works. Just slap the new data in the body and let the client read it if it wants, so maybe the protocol doesn't need any modification at all (your crappy framework code might though, but that's too bad for using those "easy-to-use" frameworks)
So, figure out the layers or logical components between each module and then you will be able to chew smaller chunks.
Then, doxygen the whole lot, making sure to use dot to create the graphs for callers and callees. This will let you see the interaction points so you can see what impact a change in one method will have (ie which callers you have to check).
Some people will say "write unit tests" but frankly, it never works with a legacy code base, to effectively unit test you have to write your code differently to how you'd normally do it. You don't have that luxury here. So a good integration test suite should be developed to test the functionality of the whole thing, then you can repeat it to make sure your changes still work. Its not as instant as unit testing (but more effective) so you'll have to invest in a build system that regularly builds and runs the (automated) integration test and tells you the results - and commit changes reasonably regularly so you can isolate changes that end up breaking the system.
The rest of the task is simply hard work running through how it works and understanding it. There's no short-cuts to working hard, sorry.
I do... but then my customers are public sector (police, EMS) who can;t afford to keep replacing their systems every few years.
This is why I advocate multiple tier applications, like the MVC boys but without their "all-in-one project" mentality. Then you can write your server side stuff in a mature, reliable language and give some kids an API that they can use to build flashy GUIs in flash or javascript or whatever fashionable toy they like this month.
And, strangely enough, everybody is happy with this approach - the kids who get to play with new toys, the elders who get to keep a solid application running, and the bosses who get reliability and flashy at the same time!
So throw away your MVC frameworks and templates and embrace the service architecture.
The new Windows is the cloud, or Azure as they call it. They want you to write your GUI for a mobile/web/whatever device and then have it connect to all-Microsoft stuff on Azure, along with Microsoft adverts and Microsoft appstore etc.
They've basically stopped believing that Windows is the only platform that gives them lock-in. Now all platforms will be lock-in!
Sorry no, WPF is the new Silverlight. Microsoft wants you to use HTML5+js (which isn;t much different from XAML+c# anyway).
They are pushing Cordova now, the Visual Studio addin that gives you support for that can do you cross platform GUIs (and on phone) and they are saying its the best way to create "Metro" apps. Expect more of this rather than WPF that is crippled partly by poor performance and partly by infghting between the Microsoft teams.
Not this time, the new guy has decided that selling Windows is no longer the lock-in platform that makes us all buy Microsoft stuff.
Now, the Microsoft stuff they want use to all buy is services, and that means they have to supply said services across every platform possible.
So, open source.NET in the hope that it'll be cheaper to port it (ie you'll do it for them) and then all those lovely.NET apps that use things like Azure and Microsoft Ads will be ported to Linux and Mac and Microsoft can reap the revenue from more people consuming their services.
Its the same story really, only this time the lock-in has shifted slightly away from Windows.
.... does the job, has a solid toolchain, and coupled with years of development experience globally and in-house, then you don't just throw that all in the trash because something newer/faster/smaller/cheaper comes out
You don't work with Windows development shops then!!
read it carefully, they will tax American companies for earning tax and then give them a tax credit for any taxes paid by those companies overseas.
So if you pay tax at 19% in the UK, America will tax you at 19% as well and then give you a 19% rebate. Net result, you pay the due tax in the UK at 91% and all's well.
Of course, if you don't pay any overseas tax for whatever reason, then you will still be charged at 19% but you won't have any credit to claim, boohoo sucks that you thought you could get away with paying no tax whatsoever.
Batteries wear out and you need a very considerable number of them to store enough energy for everyone's evening use watching TV, lighting, heating, cooking and whatnot.
I think you'd be surprised just how much gets used overnight just on street lights, let alone all the use for heating water when the cost is cheap.
A better way to store the energy is to pump water uphill, then let it drop to power turbines in the evening, but that requires a lot of infrastructure. Simply put, we don't have an easy solution to the problem of our massive energy consumption.
I understand biofuel may not be very efficient, and that's fair enough - altrhough I'd love for there to be an unlimited, carbon-free supply of cheap energy... there isn't, so we need to be a bit intelligent about it all.
the problem with solar is that you do get energy supply from it, but only during the day, so we need to come up with much more efficient ways of storing that energy. We don't have this yet.
The problem with wind is that it can be quite intermittent, not working on non-windy or too-windy days.
The problem with wave is that its in a corrosive environment so will not be as efficient if you have to continually maintain the equipment.
So what else do we have that can be used. Biofuel, and biomass generation, as part of an overall strategy is something that will help to plug the gaps in the areas when the other renewables stop working. We just need to focus it at an appropriate level rather than thinking its another silver bullet.
the listening part was just a figure of speech, as I'm sure you know if you took the time to really read what I wrote and understand it in overall context:-)
Slashdot Mirror
Ahah! suddenly the reason for getting more women in IT is clear.
Oh no, don't get me wrong - I understand the interpersonal issues involved in such a thing, but then I have also worked on government IT and understand the stupid "it says in the contract" where you cannot deviate from what they wanted even if you and your immediate contact agree it needs to be changed!
I was just suggesting that, with the lack of effective leadership a code monkey has to do what he's told, and cannot realistically make it work without backing from someone who should be providing the kind of leadership that creates and manages the relationship with the customer.
In my example, I built the relationship myself as no-one was happy with the situation. In other circumstances, I may not have that opportunity and then I'll have to do what I'm told regardless.
I find the ones who rush to use the new stuff are the ones who never quite managed to make anything with the old ones. The grass is always greener but also they can blame their lack of progress on the tools.. obviously *this* time it'll be different, just once they've had the right training and given enough time.....
Its when I was offered a job to make a system cope with the customer's increased load that I realised how damaging this is - it was written in Erlang, Ruby and Scala.
Or because some people can't cope with another variation on C++.
They're just tools guys, all these languages coming out, its just like making slightly different style hammers, only hammers don't need any training or lengthy experience to develop decent skills to use.
In such cases you take the requirements document and fulfill it exactly. Then , when the customer says "but its broke and doesn't do.." you pull out the requirements and say "it does everything you asked us to do, anything further is additional development and will be billed accordingly".
Why else do you think government IT contracts cost so much? Why else do you think Agile was invented?
The core problem is that the customer doesn't know how to achieve successful delivery, they need to be educated in fundamental agile processes, of iterative development to evolving requirements (and by evolve, I mean "as the customer figures out what they want".
I used to have similar problems with a customer, but fortunately I had a contact who knew the business. When I received the stupid requirements, I'd phone him and ask what they really meant. Then I'd develop what he said and deliver it to the customer who was always happy, not matter how far from the written spec it was (it helped that my contact was a senior guy at the customer or it wouldn't have worked)
Sortof, I find that the situation is:
You work on technology X for a while, you learn it inside and out, and you expect everyone else who is "qualified" knows what you know. but they moved on from that technology a couple of years ago and now only want to develop in Java/Erlang/Ruby/Node/Scala (* delete as applicable as depending on which year this decade you were hiring).
even more mature technologies like .NET are stuffed full of so much churn that no-one really has time to become a master of any of it. Like my mate who was brought into a ASP.NET shop, he learned their tech stack, then one day noticed the trunk had changed a lot, so went to ask the architects who said "oh yes, we decided to move forward with our DB tech, so we're using a repository pattern now". So he goes and learns all about that, does some work on a branch, then goes to merge and... its all changed again. So goes to see the architects who say "ooh no, we decided repository pattern wasn't good enough so we've changed to using entity framework". Now that shop was just stupid, but to a lesser extent this is what is happening all over the industry.
For example, this guy is getting burnt by it.
Whilst I agree that change is necessary to keep things progressing, we're almost in a throwaway culture in ITT where everything we ever did is not good enough and has to be replaced. While there are forces pushing against this (for example, all the people who want to do the big rewrite now know its a bad idea) we still have change via refactoring and flavour-of-the-month tech patterns and frameworks pushed at us.
Only when the industry gets the idea that stable is a good thing and making products is what we should be focussed on doing (ie not changing tech all the time) will this industry be as good career as the other engineering professions.
Then lie. If anyone asks, you just say "oh that, I put it on to prevent identity theft, anyone claiming to be me would not have provably correct information, I always send my correct CV to employers if I apply for a job", leaving out the implicit "fool you for looking at shit on the internet and assuming it was always true".
Now they have flipped it so you get a credit back if you get a response.
Hmm.. so now I'm wondering if its better to keep ignoring those crappy job emails I keep getting to cost the recruiters when they spam me, or to respond to them to stop LinkedIn gaining revenue from my presence.
tricky one....
Mostly pointless though, full encryption for data comms is often worthless - who cares about encrypted comms if all you're doing is looking at pictures of cats. When you're posting subversion messages criticising your local dictator, you need something better than plain old encryption anyway.
Now working with certificate authorities to manage revoked certificates is a good thing, but many of the problems with CAs are a more human problem - until we get to a point where encryption is seen as different to authentication (and even then, my comms with my bank might be encrypted but I need to know that it is my bank I'm talking to as well) and that the CA correctly handed that certificate to my bank, and not some scammer pretending to be my bank. And allowing my bank to verify that it is me that is sending them requests and not some identity thief.
The point I'm trying to make is that encryption isn't the problem that need to be solved, it all the infrastructure around it that does. Mandatory encryption isn't any solution to anything useful.
I think you're confusing the protocol verbs with a heap of javabollocks on the back end.
In most systems GET occurs much more often than POST, and if you're returning to a system after logging off, you'll be doing a lot of GETs just to restore your environment (or page view).
I think a POST+GET optimisation would be nice, but it would be an optimisation, a little like how some DBs have a 'insert, or update if already exists' statement. But you can already return data from a POST, it does break the concept but it works. Just slap the new data in the body and let the client read it if it wants, so maybe the protocol doesn't need any modification at all (your crappy framework code might though, but that's too bad for using those "easy-to-use" frameworks)
Really?
I know mono can produce real native machine code - no VM or such involved, not like Microsoft's ngen that only pre-JITs.
If they have JS compiled to native code too, then that might be interesting.
So, figure out the layers or logical components between each module and then you will be able to chew smaller chunks.
Then, doxygen the whole lot, making sure to use dot to create the graphs for callers and callees. This will let you see the interaction points so you can see what impact a change in one method will have (ie which callers you have to check).
Some people will say "write unit tests" but frankly, it never works with a legacy code base, to effectively unit test you have to write your code differently to how you'd normally do it. You don't have that luxury here. So a good integration test suite should be developed to test the functionality of the whole thing, then you can repeat it to make sure your changes still work. Its not as instant as unit testing (but more effective) so you'll have to invest in a build system that regularly builds and runs the (automated) integration test and tells you the results - and commit changes reasonably regularly so you can isolate changes that end up breaking the system.
The rest of the task is simply hard work running through how it works and understanding it. There's no short-cuts to working hard, sorry.
I do... but then my customers are public sector (police, EMS) who can;t afford to keep replacing their systems every few years.
This is why I advocate multiple tier applications, like the MVC boys but without their "all-in-one project" mentality. Then you can write your server side stuff in a mature, reliable language and give some kids an API that they can use to build flashy GUIs in flash or javascript or whatever fashionable toy they like this month.
And, strangely enough, everybody is happy with this approach - the kids who get to play with new toys, the elders who get to keep a solid application running, and the bosses who get reliability and flashy at the same time!
So throw away your MVC frameworks and templates and embrace the service architecture.
The new Windows is the cloud, or Azure as they call it. They want you to write your GUI for a mobile/web/whatever device and then have it connect to all-Microsoft stuff on Azure, along with Microsoft adverts and Microsoft appstore etc.
They've basically stopped believing that Windows is the only platform that gives them lock-in. Now all platforms will be lock-in!
I think it was brought up in the Google v Oracle case where they had their little legal tantrum over Java copyright.
Sorry no, WPF is the new Silverlight. Microsoft wants you to use HTML5+js (which isn;t much different from XAML+c# anyway).
They are pushing Cordova now, the Visual Studio addin that gives you support for that can do you cross platform GUIs (and on phone) and they are saying its the best way to create "Metro" apps. Expect more of this rather than WPF that is crippled partly by poor performance and partly by infghting between the Microsoft teams.
Not this time, the new guy has decided that selling Windows is no longer the lock-in platform that makes us all buy Microsoft stuff.
Now, the Microsoft stuff they want use to all buy is services, and that means they have to supply said services across every platform possible.
So, open source .NET in the hope that it'll be cheaper to port it (ie you'll do it for them) and then all those lovely .NET apps that use things like Azure and Microsoft Ads will be ported to Linux and Mac and Microsoft can reap the revenue from more people consuming their services.
Its the same story really, only this time the lock-in has shifted slightly away from Windows.
.... does the job, has a solid toolchain, and coupled with years of development experience globally and in-house, then you don't just throw that all in the trash because something newer/faster/smaller/cheaper comes out
You don't work with Windows development shops then!!
Oh noes, you're going to be disappointed -)
According to the BBC
but its makers have also promised it will be able to support Microsoft's next operating system at a later date.
"For the last six months we've been working closely with Microsoft to bring the forthcoming Windows 10 to Raspberry Pi 2.
silly bastards, thinking you can keep the fruit of your labor without having it stolen through threat of violence.
you mean by funding a police force, military and diplomatic corps through taxes, right?
read it carefully, they will tax American companies for earning tax and then give them a tax credit for any taxes paid by those companies overseas.
So if you pay tax at 19% in the UK, America will tax you at 19% as well and then give you a 19% rebate. Net result, you pay the due tax in the UK at 91% and all's well.
Of course, if you don't pay any overseas tax for whatever reason, then you will still be charged at 19% but you won't have any credit to claim, boohoo sucks that you thought you could get away with paying no tax whatsoever.
Batteries wear out and you need a very considerable number of them to store enough energy for everyone's evening use watching TV, lighting, heating, cooking and whatnot.
I think you'd be surprised just how much gets used overnight just on street lights, let alone all the use for heating water when the cost is cheap.
A better way to store the energy is to pump water uphill, then let it drop to power turbines in the evening, but that requires a lot of infrastructure. Simply put, we don't have an easy solution to the problem of our massive energy consumption.
I understand biofuel may not be very efficient, and that's fair enough - altrhough I'd love for there to be an unlimited, carbon-free supply of cheap energy... there isn't, so we need to be a bit intelligent about it all.
the problem with solar is that you do get energy supply from it, but only during the day, so we need to come up with much more efficient ways of storing that energy. We don't have this yet.
The problem with wind is that it can be quite intermittent, not working on non-windy or too-windy days.
The problem with wave is that its in a corrosive environment so will not be as efficient if you have to continually maintain the equipment.
So what else do we have that can be used. Biofuel, and biomass generation, as part of an overall strategy is something that will help to plug the gaps in the areas when the other renewables stop working. We just need to focus it at an appropriate level rather than thinking its another silver bullet.
Why should there be any sort of limit, other than exhausting all memory in the computer?,/i>
I don't know, maybe you should first find out which version of Excel you're having difficulty with and seeing their limitations page.
16,384 columns max in Excel apparently.
At least with LO, you can at least edit the code to fix this and make columns dynamically allocate!
the listening part was just a figure of speech, as I'm sure you know if you took the time to really read what I wrote and understand it in overall context :-)