It's funny to see you americans worry about the fuel prices; here in germany, you pay almost 1.20$ for a litre (not a gallon!). So driving costs alot of money, and the prices will raise even more.
There's a huge difference between these two. Knowing a programming language doesn't inherit that you are able to design applications. I've seen so much spaghetti code in my life, I'm really glad that development (or the ability to feed custom lines of code into your computer) became so "hard".
Sure, when I used to own a C64, I could code stuff as I wanted it to, and I knew that my code will run on everybody's else C64, too. But today, you have to develop your applications in a team, which has to run on different platforms (even Win2K and Win98 are a difference!), and has generally became very complex. But that's another story.
Read above - it is not another scripting language, it is based on ECMAscript, on which the next JavaScript-Implementation (I think it was V5) is also based.
Altough the title of that application (Windows-based of course) sounded a bit strange, it's a solid application to create (but not limited to) RPG games. There are also some nice games. I'm now thinking about pulling my old (cancelled) Phantasy Star V project out of my shoes and looking for some guys who help me. When I started the project back in 1997, I cancelled it half a year later since nobody really wanted to contribute.
In order to keep a project simple, I follow a few guidelines:
- Avoid complex functions. If your function seems to be too complex, try to swap out some code into another function.
- Document the function's parameters and the values it return.
- Flame/Kill/Bitch me for that, but I tend to create some nice graphics which show the complete project with abstract components, so you get an impression of the whole project BEFORE YOU START CODING. This makes it easier to decide which objects/functions belong to which module. See http://www.monday-rec.com/timo/rs404/rs404.html (hope that works on every browser:)
I don't know how exactly Satellites communicate with the base stations, but since they have (as far as I know) similar command structures (see the Astra information video: "The SES Astra Command Station in Betzdorf / Luxemburg is able to control satellites in their range on demand and/or in emergencies"). Hacking satellites is not a question if anyone would do it. The question is: "What can we do to prevent it?". You never know what intruders have in mind when doing such things, and you also don't know if they can. I don't know the data capacity of the uplinks/downlinks for satellite control, but isn't it possible to encrypt the data flow with ssl or similar? A well worked-out security concept is a MUST, especially if you think of that satellites cost alot of money (ranges up to unlimited, plus rocket carrier and more).
In one of my earlier projects, I've developed a database-driven file "storage" system (I wouldn't call this a file system) to store content management data in a way filesystems usually don't provide (yet). Each file had different attributes like Creator, Created, Active from/to, Object Type, Language, Version, Title and Description, complex ACL's and so on. I only did this because it is useful in that context, but I wouldn't use it as a replacent for a filesystem. The idea key->file is a nice solution when you look at this first, but you will quickly learn that it isn't a very performant solution. As one of the previous comment posters wrote: Use a filesystem what it was thought for, and use a database what it was thought for. You have Unix! Just glue the existing components together instead of writing propiraitaery (spell checker required!) application to accomplish this.
Altough the software still has a few minor bugs, it is a very good box (don't forget you get a *real* usb hard drive for your money also). I have the Archos Jukebox Recorder which I primarly use for professional audio recording (yes, that's right, we use it to create live cuts of our DJ sets at various clubs). At the studio, I just plug the recorder into the workstation, and upload the realtime-encoded MP3s to the web. Unfortunately, the Jukebox Recorder only does VBR encoding, but with around 170kbps it is sufficent.
I've been designing web pages for quite a while now, and every page scales down to almost 640x480. Click above for an example.
There is absolutely *no* need to stick to a particular resolution. maybe for the design draft, but not for the final web design.
It's funny to see you americans worry about the fuel prices; here in germany, you pay almost 1.20$ for a litre (not a gallon!). So driving costs alot of money, and the prices will raise even more.
slashdot is about stories, not about news. Even if you might have hard about this, others might not - and that's the good thing about slashdot.
have a look at the old ps/2 keyboards. don't have a look at your current keyboard.
:)
if you think about it, you'll never ask this question again
There's a huge difference between these two. Knowing a programming language doesn't inherit that you are able to design applications. I've seen so much spaghetti code in my life, I'm really glad that development (or the ability to feed custom lines of code into your computer) became so "hard".
Sure, when I used to own a C64, I could code stuff as I wanted it to, and I knew that my code will run on everybody's else C64, too. But today, you have to develop your applications in a team, which has to run on different platforms (even Win2K and Win98 are a difference!), and has generally became very complex. But that's another story.
Read above - it is not another scripting language, it is based on ECMAscript, on which the next JavaScript-Implementation (I think it was V5) is also based.
Altough the title of that application (Windows-based of course) sounded a bit strange, it's a solid application to create (but not limited to) RPG games. There are also some nice games. I'm now thinking about pulling my old (cancelled) Phantasy Star V project out of my shoes and looking for some guys who help me. When I started the project back in 1997, I cancelled it half a year later since nobody really wanted to contribute.
In order to keep a project simple, I follow a few guidelines:
:)
- Avoid complex functions. If your function seems to be too complex, try to swap out some code into another function.
- Document the function's parameters and the values it return.
- Flame/Kill/Bitch me for that, but I tend to create some nice graphics which show the complete project with abstract components, so you get an impression of the whole project BEFORE YOU START CODING. This makes it easier to decide which objects/functions belong to which module. See http://www.monday-rec.com/timo/rs404/rs404.html (hope that works on every browser
Hope that helped a bit.
-Timo
I don't know how exactly Satellites communicate with the base stations, but since they have (as far as I know) similar command structures (see the Astra information video: "The SES Astra Command Station in Betzdorf / Luxemburg is able to control satellites in their range on demand and/or in emergencies"). Hacking satellites is not a question if anyone would do it. The question is: "What can we do to prevent it?". You never know what intruders have in mind when doing such things, and you also don't know if they can. I don't know the data capacity of the uplinks/downlinks for satellite control, but isn't it possible to encrypt the data flow with ssl or similar? A well worked-out security concept is a MUST, especially if you think of that satellites cost alot of money (ranges up to unlimited, plus rocket carrier and more).
- Timo
In one of my earlier projects, I've developed a database-driven file "storage" system (I wouldn't call this a file system) to store content management data in a way filesystems usually don't provide (yet). Each file had different attributes like Creator, Created, Active from/to, Object Type, Language, Version, Title and Description, complex ACL's and so on. I only did this because it is useful in that context, but I wouldn't use it as a replacent for a filesystem. The idea key->file is a nice solution when you look at this first, but you will quickly learn that it isn't a very performant solution. As one of the previous comment posters wrote: Use a filesystem what it was thought for, and use a database what it was thought for. You have Unix! Just glue the existing components together instead of writing propiraitaery (spell checker required!) application to accomplish this.
Altough the software still has a few minor bugs, it is a very good box (don't forget you get a *real* usb hard drive for your money also). I have the Archos Jukebox Recorder which I primarly use for professional audio recording (yes, that's right, we use it to create live cuts of our DJ sets at various clubs). At the studio, I just plug the recorder into the workstation, and upload the realtime-encoded MP3s to the web. Unfortunately, the Jukebox Recorder only does VBR encoding, but with around 170kbps it is sufficent.
Cheers,
Timo