|
Java Security Rant |
 |
|
Tuesday, 12 August 2008 09:03 |
While working on that RMI project I had to adapt the Java security policy to grant all the permission necessary for RMI first. Well, can anybody tell me how the whole concept of security policies in Java is intended to improve "security" at all? Ok, applets. Applets run in a predefined VM and cannot change their policy, alright. But for an app? Where's the sense in having a policy, if I can start my own VM with whatever policy I damn well please?!
Dumb stuff. I mean, for example: Maybe I set up the machine default policy to not grant outbound SocketPermission in order to prevent Java apps from making connnections outside of my box. Then some "malicious" (ridiculing the word) app just starts a VM with it's own grant { AllPermission } policy file and does whatever it pleases to. :( What's left of the big word "security" is being forced to tackle the annoying policy files and their stupid Exceptions killing you because you did set the InhaleAirPermission, but forgot the ExhaleAirPermission, or the ExhaleWithHalitosisPermission or whatever. Damnit. ;)
Grumblegrumble,
TzeenieWheenie |
|
Remote Blog Invocation |
|
|
Tuesday, 12 August 2008 08:06 |
Well, since I've invested more than 5(!) full days of "vacation" (is that spelled right? *g*) into it, the RMI project has come quite some way already. So far the least effort went into the RMI part, which turned out to be rather easy. But my testing is all localhost, so I'm expecting some more troubles in the final environment.
So, what can I say about RMI so far? I've read recently that someone called it "crude" in comparison to .NET Remoting. I can't really second that - both .NET Remoting and RMI help you writing your application just as if you were working with local classes, the code necessary for remote activation is minimal, with a small advantage to .NET maybe. Both technologies also have severe drawbacks which really piss me off:
I'm an MCTS in .NET distributed applications, but in a professional project I'd hardly ever recommend using .NET Remoting. Why? Because .NET Remoting requires an IIS. Really people, I don't mind if web server has a full-blown GUI, or if it has some more features than I require, or if it can be extended to do practically anything from serving webpages to doing my laundry. Yet the IIS is just the exact opposite of "small and beautiful", emphasizing and symbolizing the difference between the MS and the *nix approaches to software. Say, for example, I'd be writing a small distributed tool at work - how would I ever convince anybody to set up an IIS, just so a few people can use that tool? Yeah right, ain't happenin' no time soon. :)
RMI on the other hand doesn't need a bloated webserver. Would add insult to injury as it already needs a bloated VM. (Just kidding, stop grinding those axes! ;p). No, but it still needs a server app to be started separately - rmiregistry. So, no big improvement here.
What's the deal with that? Why can't I incorporate the remoting server into my own app, why do I need my customers to start a secondary process? I know it's a good design for a large scale architecture, because it improves reliability. But hey! -give us developers some choice, will ya? I'd really like some light-weight variant of remoting, where can choose to incorporate all that remoting logic within my own app.
Well, I'll get back to work now. :)
Soon,
TzeenieWheenie
|
|
Last Updated ( Tuesday, 12 August 2008 08:48 )
|
|
Long time no blog (... I knew this would happen) |
|
|
Wednesday, 06 August 2008 11:00 |
|
Salute!
This is my first blog after a very busy period, both on work and in personal life. In fact, this is my first blog after re-locating myself, the move was rather exhausting. Seems pretty clear now that I'm not born for physical work - or any work, for that matter. :)
So that pretty much ate up all my spare time, meaning there wasn't any noticeable progress on PacMan & Co. My little projects will also be on hold for a little longer, because I just got a interesting new project I even get paid for. :p The project gives me the opportunity to lay my hands on some technology I wanted to tackle with for quite some time: RMI.
I never was much of a Java enthusiast, although I always liked their no-nonsense-pure-OO approach to things. RMI, or Remote Method Invocation, is the Java variant of a remoting technology. This means the client actually creates and uses and object on a remote server. That's basically nothing revolutionary, but I know the .NET way of remoting quite well and I'm interested in comparison to Java.
Well, the project itself is a little client/server card game, with a Java applet as client. The client is meant to represent the game in a GUI, so I'll learn some more about Swing as well. All in all a nice project.
Oh, and one more thing I have to tell you about: While setting up my IDE (Eclipse Ganymede) for the project, I figured it would be kinda cool to have it on stick, so I can fire it up anywhere I got some free time. That works just brilliant! I needed a 2GB stick, because I needed both Eclipse and the JDK in three versions (Linux, Mac, Win), but it works perfectly no matter in which environment I am. IBM - you've been wrong about almost every important technology in the last 20 years or so, but thanks again for Eclipse! ;)
So long,
TzeenieWheenie |
|
Last Updated ( Wednesday, 06 August 2008 11:08 )
|
|
New layout! |
|
|
Sunday, 08 June 2008 15:37 |
|
No news on PacMe or any of my other projects, been quite busy recently. But, I finally got to something else I wanted to do for quite some time: I made a new layout for tzeeniewheenie.dragosariz.com. Hope you like it as much as I do, currently. Hope you'll still like it when I'm back in the "hate-it-but-being-too-lazy-to-change-it"-phase. :D Soon!
TzeenieWheenie |
|
Last Updated ( Sunday, 08 June 2008 15:41 )
|
|
Pacmaniacanism II |
|
|
Friday, 16 May 2008 20:34 |
The Cocotron devs were really helpful and fixed both issues, the fast enumeration seems to be working flawlessly now and the copyWithZone: issue is dealt with too. The latter was not at all rooted in the NSArray implementation, as I assumed earlier. Backtracing in gdb I found out that NSExpression_constant, which got instantiated by the NSPredicates I used to filter, copied the constant values instead of retaining them. That's fixed in the current revision of Cocotron, thus I actually helped a tinytiny bit on that great project! Admitting that the fact leaves a little warm, soft (and bit furry *g*) feeling inside probably makes me seem a whole lot geekier - so I don't. ;)
Speaking of gdb - debugging in Windows/mingw32 still is a p.i.t.a. :( The single stepping reveals at least the method signatures, but I couldn't talk gdb into finding the sources yet. Even if I place it in exactly the same directory structure in the mingw32 environment, gdb complains about missing sources. Well, I'll have a look at that some time soon.
So, now I'm back to optimizing, because A* still has a major performance problem on Win32. FPS is about 130-150 (about twice-thrice as fast as on Mac OS), but drops to 1-2 as soon as pathfinding occurs. Backtracing again I found out that most of the time is spent in init.. methods of game entities. Which shouldn't occur at all here. I guess there's still some copying going on there, I'll try and find out what's going on there later on.
That's it for now!
Tze Ni Weeh-Nee |
|
Last Updated ( Friday, 16 May 2008 12:42 )
|
|
|
Pacmaniacanism I |
|
|
Wednesday, 14 May 2008 13:17 |
News on the Pacmaniacanism debugging: I'm not 100% sure, but it seems that either fast enumeration has been implemented a little too strict, throwing internal inconsistency exceptions if members of the collection got modified, or NSArray has not implemented correctly. The latter seems a bit more conclusive - I couldn't nail it down, but I do suspect that sometimes there are replaces happening, which cause the internal inconsistency exceptions.
Also, I still wonder what this copyWithZone business is about. It appears to have heavy impact on the performance. The path finding deals a lot with lists, all of which I implemented as NSMutableArray instances. Yes, the main reason to do so is the fact that I'm a lazy bastard and don't like re-inventing the wheel over and over again. And no, this doesn't apply to cloning yet another PacMan, thanksalot. ;D
Well, I'll try and investigate on that a little more. I got a little more complicated task at hand as well: I will try and desynchronize drawing and updating by splitting into threads. From what I've learned so far, I'm not going to use NSThread *g*, but SDL has threads as well. This will introduce a whole new set of problems, of course, but hopefully the bad performance of the NSMutableArrays will impact the game flow less (at least on multi-cores).
So long, Jimmy.
TzeenieWheenie |
|
Compiled, linked, kaputt. :/ |
|
|
Sunday, 11 May 2008 02:46 |
Did it! Finally got PacMe to compile and link for Win32 with Cocotron! Several problems I had on the way: some include files from the wxmsw / wxWidgets package were missing; it took me some time to find out that you have to define WIN32_LEAN_AND_MEAN to get rid of any unnecessary stuff. I remember that flag from back in the days of MFC, hehe. =p
Next problem was the linker: First, I had to gather all the SDL libs for Win32. Except for libSDL_gfx that was easy. I actually had to compile the latter in my MinGW environment on the WinXP vmware to get it to work, but all in all it was easier than I thought.
Immediately the next problem emerged: the linker was complaining about an undefined reference to "_WinMain@16" method. Implementing a dummy stump that calls the regular main() fixed it, but it did take me some time to find that out.
Eureka! It finally linked! :) One little happy moment *g*. But the trouble's far from over. The game exited immediately with the message that LevelCell does not recognize copyWithZone selector (which is true, neither it nor any of it's predecessors up to NSObject implement NSCopying). Obviously the NSArray/NSMutableArray implementation of Cocotron is different from Apple's - and it seems not in a good way, because I don't see any reason for a copy operation in the code. :/ Well, implementing copyWithZone: seemed to remedy this for now.
I didn't get any further then, because the next problem is really confusing: when I start PacMe directly, it exits with an NSInternalInconsistencyException and says that a certain collection has been mutated during enumeration, and that I should break in objc_enumerationMutation to debug. Now this is strange - again, on Mac OS the same code didn't have this problem. Well, I started PacMe from gdb, trying to break there - but in gdb the bug does not occur anymore!! This is a bit shitty, because I'll have to invest a ton of time to find out where the exception is thrown in the code now. :( Hopefully the Cocotron guys can help me out here.
So long,
TzeenieWheenie |
|
Last Updated ( Saturday, 10 May 2008 22:47 )
|
|
Leaks Oblivion |
|
|
Friday, 09 May 2008 14:47 |
|
I totally forgot about tinkermente with leaks tool. :P Using leaks proved extremely helpful, not only did I pseudo-leak some autoreleased objects, which told me where to put additional NSAutoreleasePools. It also immediately told me that creating an NSAutoreleasePool in loop is an incredibly bad idea. ^^ That led to some good re-coding of some of the more time-intensive loops, which left me with a good feeling of having achieved something. ;-) But I also remedied a misconception that somehow slipped into my Obj-C programming habits: By convention methods returning objects not starting with init... like [NSString stringWithFormat:] return autoreleased objects, so if you're passing them into an NSArray for example, you don't have to worry about calling release: on them. Using the leaks tool I found out that I totally forgot to release some objects I had created with an init...-method, after passing them into an array. So, very helpful insights can be gotten from leaks! :) Use leaks, folks!
TzeenieWheenie |
|
Porting - don't try this at home, kids. |
|
|
Friday, 09 May 2008 03:30 |
Porting so far was one hell of a trip. I never expected it to be easy, but I didn't think all the possible roads I had in mind would turn to be so dead-ended. Ah, well. To start it off I fired up my virtual WinXP machine and got Cygwin. I like Cygwin, I used it a lot back in the days when I was still on Windows boxes. Well, long story short: didn't work out. I couldn't get GNUstep to work on Cygwin and nobody anywhere ever said it was possible or sensible, so I gave up on that one.
Next attempt: Downloading the Windows package from gnustep.org. Really painfree, got a working environment in less than 10min. But(t): it only comes with some 3.x mingw c compiler. So what? Weeeell, I making use of some Obj-C 2.0 niceties, like properties and fast enumeration. I figured that if I don't use garbage collection (which is the only "hard" new feature) and with the details of the sparse other new features of Obj-C 2.0 out there for almost a year it would be a no-brainer to get a compiler for that. Not quite. :/ AFAIK only the latest mingw gcc supports the only two features I needed, properties and fast enumeration. So I got that one for the GNUstep environment, but it's only alpha, so what came next had to be expected: Segmentation fault. Alas, not in my code, in the compiler. Doh! :(
There you go Mr. Stroustrup, you obviously did not intend your invention for the broad masses. ;) Yeah, so after several hours of futile struggling I almost gave up. Almost. I stumbled across something called "The Cocotron" - which is intended to be full-blown, XCode-integrated cross-compiler for several platforms, especially Windows. Wow! What they're telling on their website sounds almost too good to be true. So while I'm writing this, The Cocotron is compiling in the background... I'm really excited about this, because it looks real good to me and sounds like a brilliant idea. Best of all: I wouldn't even have to compile a single line on a Windows machine. Well, we see how it turns out.
Soon,
TzeenieWheenie |
|
Last Updated ( Friday, 09 May 2008 12:47 )
|
|
PacMe! - a new project that got somewhere finally. |
|
|
Wednesday, 07 May 2008 11:10 |
I finally found some time for a project I wanted to for a long time: my own PacMan clone! Yeah, brilliant idea because there aren't like 400m of 'em already out there, I know. ;p But this is a training for me, because it's the first "real" program with more than a few hundred lines that I wrote in Objective-C.
So, what else's special about "PacMe" (except for it's sensationally stupahd name, couldn't come up with anything better yet)? Not much really, it's based on the SDL and I intend to port it to a number of platforms using GNUstep, so I hope I'll also learn a lot about Obj-C cross-platform development.
My experiences so far: Using a C-lib like SDL works like a charm in Obj-C, no problem integrating it into the OO-design of the PacMan at all. I was absolutely stunned by libSDL_ttf, by the way, using real TrueType fonts in the game with hardly any lines of code - just brilliant, very good work on that lib!
I was a bit annoyed by libSDL_gfx, though: I wanted to rotate the PacMan sprite, which is very small (16x16) by using rotozoomSurface. However, the rotation was never clean, it kept offsetting an cropping a part of the sprite for no good reason. I know about the rotated surface being the same size as the original and the cropping that may occur due to this. But this is something different: When doing 90deg rotations I expected a pixel-perfect rotated pacman, no cropping, no smoothing, not a single pixel different except for position really. Well, with libSDL_gfx I couldn't get that done, so I resided using pre-rendered sprites. It was actually fun making the little guys. :)
For the ghost I implemented A* to do a little more sophisticated path finding, which was interesting to do in Obj-C. Learned that the Cocoa collections perform very well indeed, hope GNUstep will keep up with that. While implementing the path finding, I also tinkered around with performance analysis tools like gprof (doesn't work on Intel macs, doh!) and Saturn. Saturn is cool, very much like gprof with a nice GUI. However, the method instrumentation slows down the code so significantly, that I had to isolate the code I wanted to profile. That's straight-out "I-know-where-the-bottleneck-is", hehe, but well, we all do sometimes, don't we? ;)
Next up: porting to Win32 (uuuh), tinkermente with leaks tool and some more stuff. :) I'll keep posting about the progress. Oh, and I'll do some screenshots soon. As soon as the Win32 port is working, I'll consider hosting PacMe on SourceForge or here, we'll see. :)
Have fun!
El TzeenieWheenio |
|
Last Updated ( Wednesday, 07 May 2008 08:54 )
|
|
|
|
|
<< Start < Prev 1 2 Next > End >>
|
|
Page 1 of 2 |
