I was thinking of using some light side tech (hey, I can't turn to the dark side completely in just 3 months, right?) and setting up a home server with Debian/Sendmail using the guidelines of fighting spam (graylisting and others) laid out at acme dot com. Does anybody know if those work well outside acme? I mean, they obviously do work, but has anyone have any experience to share?
Actually, System.out.println("The product of " + a + " and " + b + " is " + (a * b)); compiles as System.out.println(new StringBuffer("The product of ").append(a).append(" and ").append(b).append(" is ").append(a * b));
Use StringBuffers or memory streams to build large bodies of text. Use concatenation for dumps / logs / UI (sometimes if you generate 100 UI items via concatenation, it's better to use a StringBuffer and call setLength(0) at the beginning of the loop). Seemed obvious when I was writing the original post.
One of the main benefits of Java over C++ is memory compacting. Though the newer memory managers for C++ do a great job at arranging the memory pieces in an efficient manner as to prevent severe fragmentation. You are right of course - stl is a great tool, and the others as well.
Learn the libraries to write fast code. Don't concatenate, use StringBuffer-s. Don't use buffer.append("a" + "b") - kinda defeats the purpose:) . Don't copy arrays to add an element, use Vector/ArrayLists. Don't do linear search, use Hashtable/HashMap. Don't insert into sorted arrays/vectors, use TreeSet. Don't search inside a Vector, use HashSet. Learn how to write objects that can be hashtable keys (i.e. they must have proper equals() and hashCode()). Learn how to write objects that can be used inside Tree-s (i.e. they must be Comparable-s that have proper equals() and compareTo()). Learn how to make objects sortable or implement Comparable correctly.
Yeah, kinda basic but you will be amazed what kind of speed improvements you can get by learning these and using them whereever it is appropriate. With the proper data structure (most of them are already in the JDK) your app will fly.
Oh, and don't redraw AWT/Swing like crazy. That's why the app is so slow. Learn how to use invokeLater to avoid deadlocks/bad data, etc.
Learn how to synchronize properly with no deadlocks and what wait() and notify() are for.
Learn char and byte streams and learn memory streams (ByteArrayInput/OutputStream, etc).
Learn to love try-finally for dealing with streams.
Learn to log.
Learn by writing actual app code. Nothing beats that.
It's not about languages, it's about people. Sure, C will make you track bits and bytes and jiggle with pointers. Everyone should try that and deal with mysterious crashes, etc. And one day switch to Java and track indices in arrays and null pointers and hash codes. But at the end of the day, it's all about people, not languages. If the people are smart, and if they love the field, they will advance no matter what they're taught at school. Very few are those go that far as to learn every new language, and one day reach the level when they just don't care about the tools they use, and cat get any job done with any language at hand.
So, it's about people. We all make errors, we all over-enginner or under-engineer, we all write too complex code because of design errors. We all learn and advance. And not all of us make the best of choices.
So what? This is not just with programming though. Just programming is the most complex task humans do.
Finally, less random checks means less missed flights. I prefer they do my background check the moment I pay for the ticket with my CC, instead of when I'm trying to catch my next plane to Bulgaria for the holydays.
Something I've learned the hard way: Never modify any GUI stuff outside the main event loop thread. Well, in Win32 it is possible to get away with it (but you must know what you're doing - i.e. painting to a back buffer is OK, but not drawing into a window). In Swing/AWT you can use SwingUtilities.invokeLater(Runnable) (don't pass anything that extends Thread to it or you will make uncollectible garbage). There must be something similar in the other GUI frameworks out there.
Nope. A shift always does the same even on differently endianed systems (of course, the binary representation will be different, but the numerical value will be the same). What makes a difference is storing the integer into a file using a pointer to it and writing out sizeof(int) bytes. That will break when you move from a big-endian to a little-endian system, and will break when sizeof(int) changes. Also, combining bytes into an integer should generally work (using and | ), though you should mind word sizes, etc., but will break if you use union-s like union {unsigned int x; struct {unsigned short a, unsigned short b} y;}...
I'd really like to see these guys taking some money for the effort. But after ep. 12, I don't know... Even if Jeremy agrees, and Kyle finds some other TV executives, they still have to deal with FPS Doug first. I suppose Jeremy could try a micro combo right before Doug fires that nintendo pistol, though.
Exactly, but it's still something... So it's better to have it in the app itself or the OS (the OS can decide to use this feature if the app has only one thread that takes most of the CPU time). Some games might benefit from this... and WinRar, I suppose (I'm not sure if it supports SMP) - anything that doesn't do SMP out of the box should be sped up a little by such a thing...
...how do you propose to make a highly serially-dependant algorithm run on more than one core at a time?
Intel had a research on this. I think the idea was more or less the same as having multiple pipelines in a single core. If it could be integrated into the OS, or better of, on the chip itself (and make it manifest itself as a single CPU to the system), some nice results could be done, I suppose, but then we're still where we were a few years ago with a single CPU with many pipelines... only faster...
... behind this law, but c'mon, how many people actually understand technology? 1% of all? It's not just that the law-makers are of the old generation. They're just of those who don't get tech. Like most people. If person who understands tech gets in trouble, they can always pull a Baltar (2003) style talk and get away with just about anything, anyway.
Slashdot Mirror
Interesting... Thanks!
I was thinking of using some light side tech (hey, I can't turn to the dark side completely in just 3 months, right?) and setting up a home server with Debian/Sendmail using the guidelines of fighting spam (graylisting and others) laid out at acme dot com. Does anybody know if those work well outside acme? I mean, they obviously do work, but has anyone have any experience to share?
They required us once to use 1.1-compatible libraries (in an OSGI company), so that's stuck in my mind, but yes, you're right of course :) .
Actually, System.out.println("The product of " + a + " and " + b + " is " + (a * b)); compiles as System.out.println(new StringBuffer("The product of ").append(a).append(" and ").append(b).append(" is ").append(a * b));
Use StringBuffers or memory streams to build large bodies of text. Use concatenation for dumps / logs / UI (sometimes if you generate 100 UI items via concatenation, it's better to use a StringBuffer and call setLength(0) at the beginning of the loop). Seemed obvious when I was writing the original post.
One of the main benefits of Java over C++ is memory compacting. Though the newer memory managers for C++ do a great job at arranging the memory pieces in an efficient manner as to prevent severe fragmentation. You are right of course - stl is a great tool, and the others as well.
I'm not talking about this case, of course. I'm talking about generating a 1 mb XML file, for instance. :)
:) I said: learn about it. Don't memorize, learn.
As for "a" + "b" being evaluated in compile time - yes, but this isn't: (String)myArray.elementAt(i) + " at " + i.
See? I know
Learn the libraries to write fast code. Don't concatenate, use StringBuffer-s. Don't use buffer.append("a" + "b") - kinda defeats the purpose :) . Don't copy arrays to add an element, use Vector/ArrayLists. Don't do linear search, use Hashtable/HashMap. Don't insert into sorted arrays/vectors, use TreeSet. Don't search inside a Vector, use HashSet. Learn how to write objects that can be hashtable keys (i.e. they must have proper equals() and hashCode()). Learn how to write objects that can be used inside Tree-s (i.e. they must be Comparable-s that have proper equals() and compareTo()). Learn how to make objects sortable or implement Comparable correctly.
Yeah, kinda basic but you will be amazed what kind of speed improvements you can get by learning these and using them whereever it is appropriate. With the proper data structure (most of them are already in the JDK) your app will fly.
Oh, and don't redraw AWT/Swing like crazy. That's why the app is so slow. Learn how to use invokeLater to avoid deadlocks/bad data, etc.
Learn how to synchronize properly with no deadlocks and what wait() and notify() are for.
Learn char and byte streams and learn memory streams (ByteArrayInput/OutputStream, etc).
Learn to love try-finally for dealing with streams.
Learn to log.
Learn by writing actual app code. Nothing beats that.
Please, mod parent informative. That's someone who's read the article.
What happened to the law in Greece banning video games as a form of gambling? Gee... Just ignore the ignorant and move on.
That's for the whole world, not just the USA. Put panels on each roof globally and you won't even notice (while gaining much more energy than needed).
It's not about languages, it's about people. Sure, C will make you track bits and bytes and jiggle with pointers. Everyone should try that and deal with mysterious crashes, etc. And one day switch to Java and track indices in arrays and null pointers and hash codes. But at the end of the day, it's all about people, not languages. If the people are smart, and if they love the field, they will advance no matter what they're taught at school. Very few are those go that far as to learn every new language, and one day reach the level when they just don't care about the tools they use, and cat get any job done with any language at hand.
So, it's about people. We all make errors, we all over-enginner or under-engineer, we all write too complex code because of design errors. We all learn and advance. And not all of us make the best of choices.
So what? This is not just with programming though. Just programming is the most complex task humans do.
OEMs can integrate software with Windows XP as well. There are free tools out there to let you do the same with your own XP install. Why is this news?
Finally, less random checks means less missed flights. I prefer they do my background check the moment I pay for the ticket with my CC, instead of when I'm trying to catch my next plane to Bulgaria for the holydays.
Strange, I thought GridBagLayout was teh roxorz. Anyway, it's probably just me, and I don't do Java anymore here in the northwest.
Something I've learned the hard way: Never modify any GUI stuff outside the main event loop thread. Well, in Win32 it is possible to get away with it (but you must know what you're doing - i.e. painting to a back buffer is OK, but not drawing into a window). In Swing/AWT you can use SwingUtilities.invokeLater(Runnable) (don't pass anything that extends Thread to it or you will make uncollectible garbage). There must be something similar in the other GUI frameworks out there.
Nope. A shift always does the same even on differently endianed systems (of course, the binary representation will be different, but the numerical value will be the same). What makes a difference is storing the integer into a file using a pointer to it and writing out sizeof(int) bytes. That will break when you move from a big-endian to a little-endian system, and will break when sizeof(int) changes. Also, combining bytes into an integer should generally work (using and | ), though you should mind word sizes, etc., but will break if you use union-s like union {unsigned int x; struct {unsigned short a, unsigned short b} y;}...
Yep :)
Namely, the Clone Wars series. I think they were one of the best parts of SW.
I'd really like to see these guys taking some money for the effort. But after ep. 12, I don't know... Even if Jeremy agrees, and Kyle finds some other TV executives, they still have to deal with FPS Doug first. I suppose Jeremy could try a micro combo right before Doug fires that nintendo pistol, though.
Exactly, but it's still something... So it's better to have it in the app itself or the OS (the OS can decide to use this feature if the app has only one thread that takes most of the CPU time). Some games might benefit from this... and WinRar, I suppose (I'm not sure if it supports SMP) - anything that doesn't do SMP out of the box should be sped up a little by such a thing...
You mean IS IT SAFE?
... welcome our new Duke overlord.
... behind this law, but c'mon, how many people actually understand technology? 1% of all? It's not just that the law-makers are of the old generation. They're just of those who don't get tech. Like most people. If person who understands tech gets in trouble, they can always pull a Baltar (2003) style talk and get away with just about anything, anyway.
Let's hope this will not be the last game of flagship studios...