hm, from the online samples, IGs gonna like using this in webcit:
it wasn't about the bload, its been about the coding samples ;-P
hm, just learned the term "brogrammer" http://www.urbandictionary.com/define.php?term=brogrammer
I have to terminate my social life and stop talking about anything else than hacking.
fancy. A project that switched from see-carpet to java and groovy:
has anyone found a jvm that is usable and not enormous? (as in you have to set aside huge amounts of ram for it)
no. use a compiler and generate native code. Java interpreters are always clunky, regardless whether you name them see-carpet or whatever.
In doubt use a concept which generates intermediate c-code like vala.
The tomcat JVM uses "...20-60 MB of memory."
Here are the sources:
Sep 24 2012 6:54am from michaelmd @uncnsrd
has anyone found a jvm that is usable and not enormous? (as in you
have to set aside *huge* amounts of ram for it)
taanstaafl. the jvm's GC design philosophy favors throughput over footprint...
Sep 24 2012 1:57pm from Spell Binder @uncnsrd
A little googling says that Oracle's (Sun's) JVM requires 64 MB of
That's kind of like saying you can run Windows 7 on a 1GB netbook. You can do it, but you'll have nothing left over for a typical moderate-sized application.
I think that's one reason that a number of modern, graphically intensive games include minimum and recommended system parameters. That way, you know what you'll get if you just do the minimum.
I have some large challenges ahead, and I could use some advise.
I'm headed up a team of programmers - and I'm suspect of their abilities.
Everything here is written in ASP and VB, with a smattering of .NET. The backend SQL server is still running on MS SQL 7.0.
There's a lot of fear in this organization, which has lead to stagnation.
Now, my first instinct is to hire new programmers, and re-write everything.
However, there is 13+ years of code base, and I'm afraid of losing things if we do that.
Also, I don't want to run roughshod over the guys who have been keeping the system running all this time. They know the skeletons, and in some ways have not been allowed to do a better job than they'd like. We count on them right now to keep things going.
As programmers, what do you think? Cut bait and start over? Allow the team who got us in to this mess to help get out?
From a hardware & network perspective, we're behind but those things can easily be overcome.
Any advise would be helpful, since it's been over 15 years since I worked in programming at all.
Also, if anyone knows any good programmers looking for work in the Westchester County (New York) area, drop me a message.
Thanks in advance!
I'm not a Microsoft coder, but I'll offer a few words of devil's advocate: that this system is coded on M$ technologies should NOT be seen as a problem in and of itself. M$ catches a lot of flack from the Linux fanatics but you know, that's what they're gonna say regardless... maybe your problem is that you're on *Aging* M$ technologies. We undergo the same problems in the Java world - ask me about our projects to migrate off of IBM WebSphere and on to newer Java technologies sometime... such projects always have to compete for development with real customer needs.
Are you using ASP.NET or the classic ASP? Classic ASP is no longer the state of the art, and there's probably next to no modern library support... but MS has committed to supporting it for 10 years after Windows 8, so the death of your platform support is not imminent.
At a bare minimum, my inclination would be to say that new modules of your applicaiton should be coded in newer technologies if possible. Maybe that means newer Microsoft technologies to leverage your existing skill base. If you're stuck with some kind of monolithic server structure where everything needs to be hosted on a single Windows NT 4 box/cluster, now is the time to extend the legacy code in such a way that newer modules can be hosted on separate servers. Maybe you do need to rewrite everything. But if you try do it all in one shot rather than incrementally, in a way you can iterate on, there is a risk of project failure.
SQL Server 7 can probably be migrated to a newer SQL Server a lot less painfully than the rest of your app can be migrated from ASP Classic to ASP.NET (or rewritten in another language.)
All that being said, sometimes a product reaches the end of its lifecycle, or just becomes a complex unmaintainable mess, and your best bet is to do a total rewrite, starting only with the core features. Not all customers will migrate to the new thing, but some will.
SQL 7 is going to be upgraded to SQL 2000 first. After that, we need to make programming changes. This will allow us to run on a more current version of Windows, as well as take advantage of greater amounts of RAM, which should help performance. We've also purchased a new server using a Fusion IO card, to help reduce disk subsystem bottlenecks.
I'm not really inclined to move away from SQL Server, but I want to rethink the front end....
Luckily the system is written in a number of modules, so we can start a re-think on a case by case basis.
The most horrifying thing I've found is that the system that makes us the most money still runs in Access. They've been trying to port it for 9 years, and still haven't accomplished the job.
I've got a lot of work ahead of me.
Whether you choose to rewrite or not, you can provide your staff with the resources they need to learn new technologies. The programmers that take the initiative to use those resources are the ones you definitely want to keep. However, don't be too quick to write off the ones that don't take the initiative. If they've been living in a culture of fear, they may not be properly motivated to take what they feel might be a big risk.
In the end, it boils down to how much time and money can be spent on bringing your programmers up to speed vs. getting new programmers.
having been in similar situations...
flipping technology with an existing team is probably not a that good idea. At least not without adding new persons to the game, which is also a thing which has to be done carefully. Paid education programs are also a way to produce motivation and show you care for them.
In general, i'd rather have a look at the way they work. Maybe some stuff is wrong there.
- do they have automated tests? A lot of fear changing stuff comes from not being able to tell whether its going to be working still after the change.
- do you have staging systems where you can test changes?
- do you have SCM? if its MS Visual Sourcesafe or Clearcase, count this as "NO" Migrate to one of Mercurial or GIT
- do they do right commit comments? if no, educate them about the importance.
- do they use contineus integration tactics? Stuff like jenkins is nice.
- do they do many repetive tasks by hand? make them get automated. this steals time and gives frustration.
- do the developers also run the production + fix stuff in production which goes wrong? Do they directly communicate with customers? this makes workloads uncalculateable, separate this.
- if you have meetings, do they end in endless discussions? Is it allways the same persons causing this? get them separated. fronts build up over years, you won't fix this.
While 'agile' is just a buzword, its got several tactics which are nice.
if you have frustration at hand, one way to solve that is to visualize progress in stuff like scrum meetings.
"perfection is the enemy of the good"- are they searching for perfection? find out a way to make them produce good solutions, perfect ones will never happen.
And... watching carefully for a little while before taking actions could also be a good thing ;-)
I've been working in Windows my entire professional career, and my current company uses it extensively, for web page development, using a database backend.
Increasingly, we're moving our stuff to a cloud archetecture via Amazon.
I'd echo what Spell said, don't get rid of all the developers, as likely you have quite a treasure trove of good developers who have been stifled.
The guys you want to remove are the stagnant ones... the guys who are holding everything back because they're comfortable, don't want to learn new technologies, and think everything is fine just as they are.
Also, try to break your manpower down into groups of five people each, to work on the projects you need done. Any more than that, and you'll have crazy communication problems. Any less than that, and the team will feel overworked.
(You can have one more or one less, but the sweet spot seems tob e five). There's a good chance that one project hasn't been finished in 9 years because of massive communication problems.
SQL Server can provide a decent database engine if you want to spend the money to continue using it. Alternatively, PostgreSQL (sic?) is a nice alternative that runs on both Windows and Microsoft, and might be a good choice if you wish to gradually switch your team away from Microsoft and over to Linux.
If you're going to do that, you probably also want to gradually start coding pages in a language available to both Windows and Linux, whatever that is.
Maybe make new developement work with the new language, and slowly migrate the old pages to the new language. I am not speaking from experience here, though, so your mileage may vary.
Do not, though, be afraid to fire a stagnant worker who 'knows everything' about a part of your technology. *Someone* will rise to fill the void, and will learn what needs to be learned to get you through the problems that decision will initially create.
I write that for a few reasons. Firstly, it shows the team that nobody is indispensible. That will prevent anyone else from becoming complacent. Also, it forces people to grow... someone has to fill the void, and someone will (even if you force someone to do it). Also, the person you fired may have been sitting on some collosal problems that just wouldn't get fixed, or may have been so uninspired as to prevent things from working more efficiently, so putting someone else in that position will breath fresh air into it.
I need someone who really understands architecture, not just banging out code.
So far, I'm not real comfortable with the teams ability. Some of the design choices show inexperience at the best, ineptitude at the worst.
There is one guy who seems to have a good head for database administration, but he's been coding as well.....
If the links between components are not clearly defined, make that the first priority. Make them documented, consistent, and network transparent. Quite a lot of this will need to be done from within the existing code base.
Then, the components can be replaced one by one, in the language of your choice, using whatever disciplines you choose.
As always, avoid choosing any technology that locks you in to a specific vendor. (Except your hosting provider. Feel free to depend on them.)