|
I did. Its more fun. Its more of what keeps me coming back. The challenge of fixing something. Kinda the reason I started programming was the attraction of solving puzzles. Testing doesn't hold that same attraction, its busy work. Necessary, but busy.
But, I see your point. Just the poll is about the lure of dev, not the required bits.
This statement was never false.
|
|
|
|
|
As far as I'm concerned, the most exciting part of development is the very beginning when a need is recognized then followed by the "aha!" experience when a conceptual solution is visualized.
The next most exciting part is when a user of the developed concept talks about how "their system" successfully does whatever it was supposed to do.
Everything in between is grand but the above two points are the best.
Mike
The NYT - my leftist brochure.
dennisd45: My view of the world is slightly more nuanced
dennisd45 (the NAMBLA supporter) wrote: I know exactly what it means. So shut up you mother killing baby raper.
|
|
|
|
|
I had chosen Architecture, Data Access Layer, and Bug Fixing and tweaking, but that's mostly because I was focused on those checkboxes.
I agree wtih you 100%. I hadn't thought about it at first, but there's a real exhiliration from figuring it out, and seeing the results with the customer, beit common user or fellow dev.
This statement was never false.
|
|
|
|
|
It's just some of the people that you encounter that I would happy to do without.
Marc
Thyme In The CountryInteracxPeople are just notoriously impossible. --DavidCrow There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith
|
|
|
|
|
This is what it's all about (in most business applications). All that presentation layer, GUI design, bug fixing and testing has only one reason: To feed the right data to the data access layer and get the right data out of it.
I love windows services. Service programming is great, because I'm down low at the data acceess layer, I don't need to care about how to communicate with the common user ... all there is is the clean, unformatted, real information. A place for developers, free of beautiful-looking facades and user-readable error messages.
____________________________________
There is no proof for this sentence.
|
|
|
|
|
It's just great fun creating tool library components. Beside saving all the work of redesigning a useful interface/class/control/algorithm, there's the challange of making it as smart and bullet-proof as possible.
Which leads to a useful (yet missing) category: developer acceptance.
If another developer adopts one of my tools, I really feel like I've done something worthwhile.
A broader term, suitable for the survey, might have been 'Recognition and Acceptance' (the survey seems obsessed with two-item types). Not in an egotistical sense, but in the sense that it is an affirmation that what was done was done well and for some purpose.
Ego feeding? That could also have beeen a choice. I get that from two sources: a reputation of "that guy's apps work" from users - when they go month after month without a glitch. The other is from an anecdote: My now-former-employer let me go (after 9 years, with 2 weeks severence pay and no warning) to replace me with someone who, they claimed, codes faster. The said he had done in one year what had taken me two. It's now over three years and they're still selling my app, with a few tweaks added on. But the ego boost? That came later. I discovered they had to hire (as in ADD) a second programmer to try and get the job done. Some of the best fun you can have with your pants on . . .
Balboos
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
|
|
|
|
|
I looked for options saying "designing and building something I know will be useful in my next project as well as this one" or "making use of work done on previous projects to shorten development time on this one" but missed them both.
I suppose "tools" is as near as I'm going to get.
Brian
----@
|
|
|
|
|
Mostly because I am an odd ball in development anyhow. Most of my work is within the presentation layer, because 3D graphics is all presentation. I prefer R&D work, doing what has not been done. Repeating easy to do stuff doesn't interest me in the least and will put me to sleep, sometimes litterally. It doesn't matter if I am debugging a complex simulation, designing a new data flow, or rendering FX, if I am doing it as part of a larger "this has not been done" project, I love it all. The more on the cutting edge I am, the happier I feel.
So I put presentation layer because my main project lies completely within the presentation layer, but really they all apply, it just depends on the scope of the project.
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
?!
Developers, Developers, Developers, Developers, Developers, Developers, Velopers, Develprs, Developers! We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP Linkify!|Fold With Us!
|
|
|
|
|
I think that option is split out in to the various layers.
|
|
|
|
|
Not really.
Whoever wrote the poll assumes that everybody is writing business application software.
I don't have any Data Access Layers, Business Logic, or Presentation Layers in my projects.
|
|
|
|
|
ed welch wrote: I don't have any Data Access Layers, Business Logic, or Presentation Layers in my projects.
Really. What layers do you have?
|
|
|
|
|
Don't understand the fixation with layers . I just design my class hierarchy using OOD.
|
|
|
|
|
ed welch wrote: I just design my class hierarchy using OOD
So do I. But, other than for the smallest of application, they work themselves into layers eventually.
|
|
|
|
|
Funny, never had that happen to me, but then again I don't develop business apps
|
|
|
|
|
ed welch wrote: I don't develop business apps
So, what do you develop?
|
|
|
|
|
I don't see much use in a business/data layer if you're a framework / component developer.
|
|
|
|
|
MadHatter ¢ wrote: I don't see much use in a business/data layer if you're a framework / component developer.
Have a look at DotNetNuke and look at the way it does components (modules).
|
|
|
|
|
you obviously have application module confused with framework and component development.
you don't need much of a data or business layer for things like menu, toolbar, navigation, grid, or other type of controls you typically buy from product based 3rd party component developers. dnn is an application, and things built for it are application specific, one could say, business logic specific, and therefore are not component objects in the sense that the others are.
thats not to say the obsessive developer who knows nothing outside of an n-tier architecture wouldn't try to write components like that (heavens knows the people at my work would try, as anything without a business object is just wrong).
business and data layers are used for data persistence in scalable applications. if 1) your code does not apply the logic of data persistence or 2) is not a scalable collective of objects, then it is not even a candidate for these "layers.". if you have a toolbar that will open and save its data to some isolated storage file, then there is no need to abstract out that functionality so it can be extended to godonlyknows because it will never need to be overridden by the user of that component. if you're writing a framework (.net framework anyone?) and you're implementing some application configuration class, why not hard code the layer that actually loads the file? because thats the route Microsoft took.
thats the kind of thing I'm talking about.
|
|
|
|
|
games
|
|
|
|
|
ed welch wrote: games
Ah.... Fair enough. I never thought of that.
|
|
|
|
|
Heh heh... I'll chomp.
Asset management:
Where are your textures located, where on disk, so you have a resource manager.
Data Access Layer.
Sound, Texture, Mesh, Not to mention scripts for game objects, which brings me to:
Game Objects:
Characters, vehicles, triggers, AI, etc.
Business Objects.
Graphics Engine:
Then you have the rendering pipeline, the graphics engine, which correct me if I'm wrong, falls into...
Presentation Layer.
Just about every game consists of the same pieces as a business app, they're just grouped differently.
This statement was never false.
|
|
|
|
|
Chris-Kaiser wrote: Where are your textures located, where on disk, so you have a resource manager.
sorry man, but thats file IO not data access. layers represent abstracted functionality, chances are you couldnt store the resources in anything else but in file. the whole idea behind a data access layer is that you can change the data repository without affecting the application. if your resource manager simply opens a file, then you're going to be hard pressed to switch out that functionality without having to rewrite the whole thing.
Chris-Kaiser wrote: Game Objects:
Characters, vehicles, triggers, AI, etc.
Business Objects.
business objects reflect the database they're stored in, so, no, those are just objects. they are not subject to change in game, and do not require updates to what they look like. a business object would be a player account object, which would get updated when you payed your monthly subscription fee... I have seen games written using these layers, and its not to say that a game *couldn't* implement these things, its just that game developers come from a different school of thought (small, concise, and light weight).
Chris-Kaiser wrote: Graphics Engine:
Then you have the rendering pipeline, the graphics engine, which correct me if I'm wrong, falls into...
Presentation Layer.
Just about every game consists of the same pieces as a business app, they're just grouped differently.
I wonder if you've ever participated in a strict n-tier system. presentation layers are capable of rendering business objects. business objects are capable of accessing the data layer, and the data layer is responsible for persisting its state to a data repository. drawing a player model does not represent a presentation layer. it is data presentation, but not in the same sense that an architecture that *actually* implements these abstract layers.
every program has IO, business logic, and some have a UI. these are not the same as an abstracted n-tier architecture, otherwise every application in the world would be some massively scalable system.
|
|
|
|
|
MadHatter ¢ wrote: sorry man, but thats file IO not data access.
Sorry man, but if you're thrashing your cache by not reusing your textures due to not managing them in a "data access layer" or resource manager, then the game will not preform well most of the time, unless its a trivial game.
You have a host of textures, meshes, skeletal files, etc. Hopefully aligned on the disk according to access grouping, but still, you won't be able to hold everything in memory, so for a given level you'll load most of what you need, but on systems that don't have a gig of ram, PS2 for instance, then you'll have to have a priority based system that loads what's needed, caches it, and dishes it out to the game objects that need it. Prioritized so that if it fills up and a request comes in that isn't cached, the least used resource will get tossed. So this is a data access layer, just not in the sense that you are thinking about it. You have to manage your data access.
I suggest that you read Scott Bilas' article[^] that was in Game Programming Gems 1 regarding resource management and how its really a database. His view even holds that every application is a database due to the very nature of managing data.
MadHatter ¢ wrote: I wonder if you've ever participated in a strict n-tier system. presentation layers are capable of rendering business objects. business objects are capable of accessing the data layer, and the data layer is responsible for persisting its state to a data repository. drawing a player model does not represent a presentation layer. it is data presentation, but not in the same sense that an architecture that *actually* implements these abstract layers.
I bet you do.
I work on one now. N-Tier, an application tcp server that our web accesses as well a traditional gui, then there's the mobile apps I build that interface with that app server through a webservice. I also have to maintain a disconnected database on the device and manage a transaction server to upload them when connectivity is established. All of it is dynamic in that the main framework knows nothing of the business at hand. It interrogates assemblies to get the data definitions, business libraries, and embedded modules.
I have also worked on large scale game development. The last one in 1999 for Angel Studios on the Smuggler's Run PS2 launch title. They got picked up by Rockstar and are now Rockstar San Diego.
So, while you may think I'm speaking out of my ass, I have experience with what I'm saying on both the enterprise and game dev fronts. Its not just theoretical.
Next.
Addendum: Also, the rendering pipeline... its a presentation layer. The graphics engine. If your game objects need to know whether they needs to use DirectX or OpenGL, then you haven't abstracted your presentation layer enough.
This statement was never false.
|
|
|
|
|
MadHatter ¢ wrote: business objects reflect the database they're stored in, so, no, those are just objects. they are not subject to change in game, and do not require updates to what they look like. a business object would be a player account object, which would get updated when you payed your monthly subscription fee... I have seen games written using these layers, and its not to say that a game *couldn't* implement these things, its just that game developers come from a different school of thought (small, concise, and light weight).
Missed this section in the last reply.
Business objects don't have to reflect any database. They can comprise data from a table, multiple tables, or even from a webservice. Say, a stock ticker. This is some pretty limited thinking on your part. I take it, you don't like that language of: Data/Business/Presentation.
A business object in the game context would be say: an NPC. Its comprised of base data: sound, texture-mesh-skeletal(3d)/png(2d), then behaviors from either a script (acquired through the resource manager(data access) *, and will be called upon by the graphics engine to either draw itself, or to obtain the files necessary to draw it by the engine itself. So all three pieces are still in play. The model still fits.
Now to have a truly data driven solution you'd want to break these out into the different layers. The GameObject would load its resources from the resource manager. The manager will only retain a single copy, even though multiple game obejcts might be using it, in the case of trees for instance, and HOPEFULLY your game objects are going directly to the disk to get the resources themselves. The AI subsystem would also query the game objects to get at the resources required, to perform the update.
Anyone who thinks that a game doesn't also consist of these layers hasn't thought it out, or are biased against the language such that they just can't see it.
See the link I gave in my other reply. Game developers are moving more in the direction of breaking up the projects in this manner. Especially if they are licensing a game engine.
This statement was never false.
|
|
|
|
|