...Soviets had supersonic air to surface cruise missiles and surface to surface missiles. It's where the Indian tech comes from. Kitchen and Sunburn were the ones that spring to mind immediately.
As an agnostic (and ex-Catholic) I'm no defender of the church by any means but asking the other poster for examples of "democracy at work within the church" in an attempt to refute that the Church and Scientology are very different in their treatment of people is patently absurd. I might as well as you to provide us of examples of "democracy at work within a corporation" and then contend that a corporation is as dangerous and abusive as Scientology - which, of course, we know is for the most part incorrect.;)
...now that you have one of the tools for your toolbox.
As you appear to be realizing, learning a programming language is like having a particular type of hammer. Each computer language you learn is another type of hammer. You don't have to have more than one hammer, but since some hammers are better some types of construction than others - the more hammers you have (within reason) the more flexibility you have in building things.
Congratulations on absorbing some of the aspects of Java, keep shining that hammer and get ready to learn how to build a doghouse. How ambitious you are should determine what type of doghouse you're going to build first (I recommend knocking out a few doghouses before moving on to small sheds.)
A good doghouse to start with would be (with a Java hammmer) a calculator (try an applet.) You have a UI, you have a simple to understand feature set, you don't have to think to much about the spec (this time), and you can leave persistence to your next doghouse.
Doghouse number 2 could be something like a very crude text editor with (if you feel adventurous) a pluggable UI (through the classloader) and one that not only loads/saves edited files, but has undo/redo capabilities, and most importantly saves it settings in an options file of some sort (yes, there are other ways to do this but it is good practice for learning persistence, dirty flagging, the impact of your choices when creating your own little file format, et cetera.)
Doghouse number 3 should be your first foray into network related code. Write a simple GUI FTP client. If you're feeling adventurous, not only make the UI plug-in capable (again through dynamic classloading or through another method if you wish), but make sure that the user can stretch/shrink the UI. Make sure the user has persisted settings/options. When writing your UI code, try to make it possible for the user to switch UI languages on the fly. This means create your own format for loading/saving this language data.
Now, there are shortcuts to pretty much all of the aspects of these little mini-applications, but implement these things yourself. You're not doing these things for the purpose of learning how you should implement a particular feature for a particular future professional application, you're doing these things so that you gain experience in realizing how different aspects of applications meet and interact (especially using a pluggable GUI, this will really force you to separate your codebase better.)
Once you've written a workable little ftp client, you're ready to take those basic construction techniques are start building sheds. What those sheds are are pretty much up to you, but pick something that interests you.
Once you can handle a shed or two, you can tackle a house, analogy beaten into ground, et cetera, ad nauseum.
Like some of the earlier posters said, it's just like becoming a writer. You can have a great typewriter, know all the rules of grammar, have tons of vocabulary at your fingertips, but you MUST WRITE to become a good writer. You do software engineering to become a good software engineer. It's that simple. Stuff will go wrong, you'll f*** things up, you'll paint yourself into corners. You'll make stuff you think is crap, but every single time you do it you make sure that you're learning something about why things ended up the way they did (good or bad.)
I always found that to be a very strange move by Adobe, so strange that I wonder if there was someting outside of their control. Maybe we'll see a made for tv movie about it someday;) (a la 'Pirates of Silicon Valley')
There's only one reason why there's no Flash or Java on the iPhone - because you wouldn't be forced through the app store if they had either of them (unless they crippled them extensively like they were thinking about with Flash until people started pointing out - "uh, if the flash experience is the problem, why will you let the flash experience run on the iPhone only we still have to go through the app store?" - LOL ) and you wouldn't need Apple's development machines and environment to write software for it. If they could somehow get away with not implementing HTML5 (which they can't) you could rest assured it wouldn't be on the iPhone/iPad/iWhatever either.
I can't believe the number of people who lap up this Apple drivel - flash experience is poor? LOL, I wonder how it managed to get such huge market penetration and basically pervade every aspect and corner of the web - oh, I guess because it's crap, right Apple?
Of course, luck is a possibility in all things, but I am arguing that it is not an appreciable factor in air to air combat. It does seem to apply to whether or not my wife is nice to me in the morning though... I am, apparently, unlucky this morning...
I know quite a few actually, although they're all F-14 and F-18 pilots so maybe it's a Naval 'aviator' thing, but they certainly don't ascribe anything to 'luck', although they all seem to have the same lame mustache and drive red corvettes - weird. The kill ratio between US and/or Israeli forces during their deployments/conflicts in the middle east have nothing to do with luck, and in actuality are only somewhat the result of superior technology; for the most part its tactics, training, and integration.
...the point being that even with the designs, and 'consultants' from Israel, and even entire aircraft from Israel and the Soviet Union, they can barely build what is arguably a 4th generation aircraft after 20 years of effort; ergo, it seems safe to say that a FAR FAR more complicated manufacturing process for a 5th generation stealthy fighter would be quite a mountain to climb for them. The only worry about China and advanced aircraft are that they simply buy them outright from the Russians (included the PAK-FA.)
People also forget that you can put two pilots in identical aircraft and the one with superior tactics and training will be the victor.
The J-10 is considered to be a 4th generation fighter, but the Chinese did not engineer the plane themselves - it is based heavily on the IAI Lavi, Russian engines, and Israeli flight controls (not the same as the Lavi.) The J-10 is the second attempt at the J-9 which was cancelled long long ago and even as such took nearly 20 years of development to get to where it is, even though it is basically a foreign born aircraft. Needless to say, the Chinese will be buying their PAK-FAs, just likey they do their other Sukhois (and engines, and electronics, and flight control systems...)
It's not a case of them 'reverse engineering' the fighter, the primary obstacles to creating aircraft like this isn't an aircraft design issue, it's an engineering issue. The materials, production lines, resources, manufacturing expertise, et al., necessary to successfully implement the F-22 or PAK-50 is incredibly prohibitive. Ever wondered why China is only now just starting to produce fighter aircraft of the 3rd/4th (more like 3.5) generation on its own? They've had high quality imported aircraft for almost two decades now and they can't make anything themselves that compares to a 4.5 generation fighter. This is what one would term a 'non trivial' tast;).
Well, up until 2 years ago I was the software architect for a software company (bought by SIEMENS 3 years ago) that did nothing but sensor fusion and I can tell you that false positives are the entire roadblock to deploying production solutions. We had tons of great demos - that if you happened to match the scenario requirements you could use, unfortunately those perfect fits were rare. The software was still valuable, but gathering useful metrics and or discerning an 'alarm' condition with behavioral analysis is generally speaking, not currently feasible. A simple thing, to a human, such as someone leaving an object behind (a bomb scenario) is frightfully difficult to pull off in just about any environment you'd actually wish to monitor for such activity. Simply detecting someone moving in the wrong direction is incredibly difficult to handle in general usage scenarios. Simple to demonstrate, difficult to put to practical use, that's the current story of behavioral analysis.
...(if granted) never stand up in court unless something truly novel was listed because this sort of 'data fusion' has been going on in the security industry for the past 10 years.
There is a very specific reason you will only see this sort of 'product' in testing for the next 10 years - 'false positives.' That's a very very important phrase in the security industry because software based solutions are supposed to act as force multipliers (although historically they're used to reduce forces in order to lower costs through automation, not to augment it) and if you've a high 'false positive' rate (as ALL of these behavioral analysis systems do) you actually impede normal security operations. Research in this area of physical security is active and ongoing, but veyr unlikely to produce anything usable except in very specific scenarios (objects left behind, loitering, et cetera.)
...to greater and lesser degrees. You will always find yourself, if you work for companies larger than 10 people in size, noticing that there are people who simply clock their time and those who actually work - regardless of whether this is in IT or at a law firm or even a hospital. Even companies of 10 or less can have unmotivated employees who are only there for the paycheck and have no interest in actually accomplishing anything.
One of the reasons people strive to work at companies like Google, Microsoft, Apple, startups, and any other company that makes employment challenging, is the opportunity to be on teams that are motivated. Teams where you can learn something not only from what you end up producing, but from each other, and even (on rare occasions) from your management.
If you find yourself working someplace where people just jerk around all day you should realize a few things, first that management likely doesn't understand the projects or people they are managing so they're either just PHBs (pointy haired bosses) or nice versions of the PHB. If that wasn't the case, they would certainly not put up with that sort of behavior - it would be in their best interests to keep costs down and get rid of dead wood. Second, that unless you're division/department is not the primary revenue generator for your company, you should worry; because, your management doesn't know how to manage engineers, and your engineers don't seem to give a sh**.
If you're as junior as you seem to be, I would recommend that you learn what you can at this job and move on. Save up a few grand in the bank, keep your personal costs low (ignore that 'bimmer' you've always wanted), and find a startup or other small company that makes software. It is like being paid to attend graduate school for engineering/marketing/business usually with other highly motivated people.
I'm sorry, but that's not a myth. I'm sure, like all things, it depends upon time and place, but I assure you that the scanline hidden surface removal code I recently wrote that uses a span based methodology is entirely dependent upon good commenting so that debugging can involve someone other than myself. There aren't many software rendering specialists out there anymore. My code has excellent naming conventions, is organized clearly, but if you don't understand all the factors involved it would be laborious even for myself to debug this a year from now. Documenting the edge cases, the oddities, the factors other design decisions elsewhere in the system have made to impact choices in this code, it critically important.
Hopefully it is commented thoroughly enough that someone reasonably proficient in Java and 3D could understand why things work they way they do. All of this is, of course, also included in a design overview document for this aspect of the system, but documents like that tend to get lost as time goes by. Documenting in the code why exactly we, for example, interpolate colors the way we do and then clamp them to an applicable range in critical to avoid someone messing up overbright lighting.
Now, of course, this need doesn't apply in all scenarios. I don't heavily comment the model loader's methods (although they are well commented) to explain how we manage endian-ness and why, although I do mention to beware of this issue, but that's because in 3D this is a fairly common thing to have to support; ergo, I expect a developer with 3D experience to understand basic issues with modeling formats (if not the specifics of a particular format.)
Well, if you and I are going to wait until employer's attitudes become 'reasonable', we should start auditioning for 'Waiting for Godot';). I would settle for employer's in technology companies not considering the production/management/deployment/support of software as the equivalent of making lipstick. Just something you can box, ship, manufacture without understanding...
Slashdot Mirror
http://nehe.gamedev.net/
There are tons of places. Start with NeHe.
LOL - 'tarted up' - Love it ;)...
...Soviets had supersonic air to surface cruise missiles and surface to surface missiles. It's where the Indian tech comes from. Kitchen and Sunburn were the ones that spring to mind immediately.
As an agnostic (and ex-Catholic) I'm no defender of the church by any means but asking the other poster for examples of "democracy at work within the church" in an attempt to refute that the Church and Scientology are very different in their treatment of people is patently absurd. I might as well as you to provide us of examples of "democracy at work within a corporation" and then contend that a corporation is as dangerous and abusive as Scientology - which, of course, we know is for the most part incorrect. ;)
...now that you have one of the tools for your toolbox.
As you appear to be realizing, learning a programming language is like having a particular type of hammer. Each computer language you learn is another type of hammer. You don't have to have more than one hammer, but since some hammers are better some types of construction than others - the more hammers you have (within reason) the more flexibility you have in building things.
Congratulations on absorbing some of the aspects of Java, keep shining that hammer and get ready to learn how to build a doghouse. How ambitious you are should determine what type of doghouse you're going to build first (I recommend knocking out a few doghouses before moving on to small sheds.)
A good doghouse to start with would be (with a Java hammmer) a calculator (try an applet.) You have a UI, you have a simple to understand feature set, you don't have to think to much about the spec (this time), and you can leave persistence to your next doghouse.
Doghouse number 2 could be something like a very crude text editor with (if you feel adventurous) a pluggable UI (through the classloader) and one that not only loads/saves edited files, but has undo/redo capabilities, and most importantly saves it settings in an options file of some sort (yes, there are other ways to do this but it is good practice for learning persistence, dirty flagging, the impact of your choices when creating your own little file format, et cetera.)
Doghouse number 3 should be your first foray into network related code. Write a simple GUI FTP client. If you're feeling adventurous, not only make the UI plug-in capable (again through dynamic classloading or through another method if you wish), but make sure that the user can stretch/shrink the UI. Make sure the user has persisted settings/options. When writing your UI code, try to make it possible for the user to switch UI languages on the fly. This means create your own format for loading/saving this language data.
Now, there are shortcuts to pretty much all of the aspects of these little mini-applications, but implement these things yourself. You're not doing these things for the purpose of learning how you should implement a particular feature for a particular future professional application, you're doing these things so that you gain experience in realizing how different aspects of applications meet and interact (especially using a pluggable GUI, this will really force you to separate your codebase better.)
Once you've written a workable little ftp client, you're ready to take those basic construction techniques are start building sheds. What those sheds are are pretty much up to you, but pick something that interests you.
Once you can handle a shed or two, you can tackle a house, analogy beaten into ground, et cetera, ad nauseum.
Like some of the earlier posters said, it's just like becoming a writer. You can have a great typewriter, know all the rules of grammar, have tons of vocabulary at your fingertips, but you MUST WRITE to become a good writer. You do software engineering to become a good software engineer. It's that simple. Stuff will go wrong, you'll f*** things up, you'll paint yourself into corners. You'll make stuff you think is crap, but every single time you do it you make sure that you're learning something about why things ended up the way they did (good or bad.)
Good luck!
Exactly, when they say "much darker" I'll be interested if they mean "as in Dark Knight" darker; ergo, NOT suitable for children - or my wife.
I always found that to be a very strange move by Adobe, so strange that I wonder if there was someting outside of their control. Maybe we'll see a made for tv movie about it someday ;) (a la 'Pirates of Silicon Valley')
There's only one reason why there's no Flash or Java on the iPhone - because you wouldn't be forced through the app store if they had either of them (unless they crippled them extensively like they were thinking about with Flash until people started pointing out - "uh, if the flash experience is the problem, why will you let the flash experience run on the iPhone only we still have to go through the app store?" - LOL ) and you wouldn't need Apple's development machines and environment to write software for it. If they could somehow get away with not implementing HTML5 (which they can't) you could rest assured it wouldn't be on the iPhone/iPad/iWhatever either.
I can't believe the number of people who lap up this Apple drivel - flash experience is poor? LOL, I wonder how it managed to get such huge market penetration and basically pervade every aspect and corner of the web - oh, I guess because it's crap, right Apple?
Of course, luck is a possibility in all things, but I am arguing that it is not an appreciable factor in air to air combat. It does seem to apply to whether or not my wife is nice to me in the morning though... I am, apparently, unlucky this morning...
I know quite a few actually, although they're all F-14 and F-18 pilots so maybe it's a Naval 'aviator' thing, but they certainly don't ascribe anything to 'luck', although they all seem to have the same lame mustache and drive red corvettes - weird. The kill ratio between US and/or Israeli forces during their deployments/conflicts in the middle east have nothing to do with luck, and in actuality are only somewhat the result of superior technology; for the most part its tactics, training, and integration.
Luck? LOL. I doubt you'll find any fighter pilots who think luck will keep you alive.
...the point being that even with the designs, and 'consultants' from Israel, and even entire aircraft from Israel and the Soviet Union, they can barely build what is arguably a 4th generation aircraft after 20 years of effort; ergo, it seems safe to say that a FAR FAR more complicated manufacturing process for a 5th generation stealthy fighter would be quite a mountain to climb for them. The only worry about China and advanced aircraft are that they simply buy them outright from the Russians (included the PAK-FA.)
People also forget that you can put two pilots in identical aircraft and the one with superior tactics and training will be the victor.
The J-10 is considered to be a 4th generation fighter, but the Chinese did not engineer the plane themselves - it is based heavily on the IAI Lavi, Russian engines, and Israeli flight controls (not the same as the Lavi.) The J-10 is the second attempt at the J-9 which was cancelled long long ago and even as such took nearly 20 years of development to get to where it is, even though it is basically a foreign born aircraft. Needless to say, the Chinese will be buying their PAK-FAs, just likey they do their other Sukhois (and engines, and electronics, and flight control systems...)
It's not a case of them 'reverse engineering' the fighter, the primary obstacles to creating aircraft like this isn't an aircraft design issue, it's an engineering issue. The materials, production lines, resources, manufacturing expertise, et al., necessary to successfully implement the F-22 or PAK-50 is incredibly prohibitive. Ever wondered why China is only now just starting to produce fighter aircraft of the 3rd/4th (more like 3.5) generation on its own? They've had high quality imported aircraft for almost two decades now and they can't make anything themselves that compares to a 4.5 generation fighter. This is what one would term a 'non trivial' tast ;).
Agreed. Sadly using the cameras to monitor hotspots is the fate of many a multi-million dollar camera system (just ask the US Border Patrol, lol.)
Well, up until 2 years ago I was the software architect for a software company (bought by SIEMENS 3 years ago) that did nothing but sensor fusion and I can tell you that false positives are the entire roadblock to deploying production solutions. We had tons of great demos - that if you happened to match the scenario requirements you could use, unfortunately those perfect fits were rare. The software was still valuable, but gathering useful metrics and or discerning an 'alarm' condition with behavioral analysis is generally speaking, not currently feasible. A simple thing, to a human, such as someone leaving an object behind (a bomb scenario) is frightfully difficult to pull off in just about any environment you'd actually wish to monitor for such activity. Simply detecting someone moving in the wrong direction is incredibly difficult to handle in general usage scenarios. Simple to demonstrate, difficult to put to practical use, that's the current story of behavioral analysis.
...(if granted) never stand up in court unless something truly novel was listed because this sort of 'data fusion' has been going on in the security industry for the past 10 years.
There is a very specific reason you will only see this sort of 'product' in testing for the next 10 years - 'false positives.' That's a very very important phrase in the security industry because software based solutions are supposed to act as force multipliers (although historically they're used to reduce forces in order to lower costs through automation, not to augment it) and if you've a high 'false positive' rate (as ALL of these behavioral analysis systems do) you actually impede normal security operations. Research in this area of physical security is active and ongoing, but veyr unlikely to produce anything usable except in very specific scenarios (objects left behind, loitering, et cetera.)
You don't think you could hide conditional behavior in an iPhone App that would get through to the store? ;) Obfuscated C code contests anybody?
...to greater and lesser degrees. You will always find yourself, if you work for companies larger than 10 people in size, noticing that there are people who simply clock their time and those who actually work - regardless of whether this is in IT or at a law firm or even a hospital. Even companies of 10 or less can have unmotivated employees who are only there for the paycheck and have no interest in actually accomplishing anything.
One of the reasons people strive to work at companies like Google, Microsoft, Apple, startups, and any other company that makes employment challenging, is the opportunity to be on teams that are motivated. Teams where you can learn something not only from what you end up producing, but from each other, and even (on rare occasions) from your management.
If you find yourself working someplace where people just jerk around all day you should realize a few things, first that management likely doesn't understand the projects or people they are managing so they're either just PHBs (pointy haired bosses) or nice versions of the PHB. If that wasn't the case, they would certainly not put up with that sort of behavior - it would be in their best interests to keep costs down and get rid of dead wood. Second, that unless you're division/department is not the primary revenue generator for your company, you should worry; because, your management doesn't know how to manage engineers, and your engineers don't seem to give a sh**.
If you're as junior as you seem to be, I would recommend that you learn what you can at this job and move on. Save up a few grand in the bank, keep your personal costs low (ignore that 'bimmer' you've always wanted), and find a startup or other small company that makes software. It is like being paid to attend graduate school for engineering/marketing/business usually with other highly motivated people.
Good luck!
I'm sorry, but that's not a myth. I'm sure, like all things, it depends upon time and place, but I assure you that the scanline hidden surface removal code I recently wrote that uses a span based methodology is entirely dependent upon good commenting so that debugging can involve someone other than myself. There aren't many software rendering specialists out there anymore. My code has excellent naming conventions, is organized clearly, but if you don't understand all the factors involved it would be laborious even for myself to debug this a year from now. Documenting the edge cases, the oddities, the factors other design decisions elsewhere in the system have made to impact choices in this code, it critically important.
Hopefully it is commented thoroughly enough that someone reasonably proficient in Java and 3D could understand why things work they way they do. All of this is, of course, also included in a design overview document for this aspect of the system, but documents like that tend to get lost as time goes by. Documenting in the code why exactly we, for example, interpolate colors the way we do and then clamp them to an applicable range in critical to avoid someone messing up overbright lighting.
Now, of course, this need doesn't apply in all scenarios. I don't heavily comment the model loader's methods (although they are well commented) to explain how we manage endian-ness and why, although I do mention to beware of this issue, but that's because in 3D this is a fairly common thing to have to support; ergo, I expect a developer with 3D experience to understand basic issues with modeling formats (if not the specifics of a particular format.)
...a shitty deal. Ba dum dum...
Mod parent up please
...exactly this, and have done it for 8 years or more. Wonder why they're re-inventing the wheel? It will be painful, I assure you :).
Well, if you and I are going to wait until employer's attitudes become 'reasonable', we should start auditioning for 'Waiting for Godot' ;). I would settle for employer's in technology companies not considering the production/management/deployment/support of software as the equivalent of making lipstick. Just something you can box, ship, manufacture without understanding...
It is illegal to, without the permission of the employee, convert a full time worker to a contract worker (for several reasons.)