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.)
I'm in an increasingly peculiar position at work now, and I wonder if I could get a little help in one specific area.
My boss insisted that we create software that runs in the Windows environment.
He came to this decision long ago because he's familiar with the operating system, and could therefore do maintenance on any machines running with that operating system. He also has a bias against free software, because he has been burned several times by people who didn't really understand the full costs of working with such software, and failed to anticipate certain concerns well.
Today, he has had a change of heart. I suspect his exposure to the Android OS, layered on top of Linux as it is, caused him to rethink his position.
He has asked me a few times how difficult it would be to migrate everything over to Linux, etc.
I'd love to do this, because:
1. I've always wanted to program for posix operating systems.
2. I want to expand my skillset out of Windows.
3. Linux seems like it will be more stable than the many-and-varied ways in which Microsoft fucks with the Windows OS to make it harder to do relatively simple things (like editing a text file and saving it without any problems... yes, Windows has become so bad that you can't always do this without having to go through your asshole).
4. We might be able to save money using Linux instead of paying for Windows licenses.
5. Less of a hassle during installation. Maybe.
So why am I posting this in Programming instead of Linux? Because I need to start this migration with simple things before I get to the larger things, and the simple thing I want to focus on right now is the Windows service integration vs. posix daemons.
(continued in the next post)
In Windows, our long-running services integrate with a Service Control Manager (SCM). The SCM provides a framework for controlling services, by letting you stop, start, pause, and perhaps send specialized signals to the service through its framework. You have to make specialized calls to the operating system to install or remove the service, and those calls can be made in such a way as to have the service start automatically, or manually.
I know enough about posix to know that you can't call a function to install the daemon, that such things are handled by scripts that invoke your service and that other scripts control whether or not your daemon is started automatically or manually, so I am not concerned about that exactly.
I'm more interested in what it takes to set up a daemon. I assume that it has to listen to signals (like KILL and HUP) and react appropriately to those signals.
Basically, I want to take the core code I use now for creating a Windows service, and add to it, to make it also create a posix daemon, so I don't have to write specialized code for Windows vs. posix. That is, I want to derive a class in C++ from a 'process' class (perhaps), who then calls functions like run(), on_stop(), on_pause() or the like depending on the signal received (in posix) or the SCM signal received (in Windows).
I already have code that helps me set up a Windows NT service easily by deriving a class and overriding its Run, OnStop, OnPause, etc. functions. I think I want something similar for posix, but is identical enough that a compiler #define would cause either the NT Service or Posix code to get compiled as appropriate.
I would be willing to make this code available to everyone, since I don't think something like this is a core company holding, but would be very useful to a lot of people.
And the majority of this code would exist as a series of headers. I don't like writing dynamic or static libraries, preferring header libraries for something like this. That would help to keep everything light, although you'll need to use certain macros to help create the 'main' function, etc.
So, I suppose, I'm looking for advice. Some of you (IG in particular) have a lot of experience writing daemons for posix. I have a lot of experience writing NT services. I'd like to merge these two expertises into a single code set that can work for both OSes.
Later, I'll post the code I currently have for creating an NT service. This code is a lightly modified version of code I found on Dr Dobbs. The modifications were intended to make it easier to create an NT service (derive a class and call a macro).