remember xamarian introducing the java to see-carpet transpiler that can convert the whole android userland?
now you can test whether they were doing it right.
difference between the suits as far as value.
I have no idea why I think this question has been asked before, I am not writing a game I am just wondering what others would do.
Wed Jul 25 2012 11:14:05 EDT from IGnatius T Foobar @ UncensoredLovely. I'm sure Miguel de Idiot has a Vista Phone in his pocket and is heaping praise upon its innovative and wonderful experience.
I like his rant about them selling the Nokia Lumnia 900 (the top notch product) for 20$ which imho is next to we don't want to pay the costs for disposal of the unsold units.
Microsoft cutting the upgrade path to windows 8 was probably as good to windows 7 phones as the (to early) anouncement of the Apple Macintosh to the Apple Lisa.
btw, mdidiot is developing/trying to sell see-carpet for android and i-something, so you can easily port your app for the vista fon to them ;-)
I guess developing a toolkit to run objective c-code on android more easily sounds like a more clever business idea to me. Or... maybe transpile the java stuff to objective c.
Ontario Mega Finance Group!
s.b. wasted 12 Mio. US-Dollar into xamarian.
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.