So here's an interesting angle (from someone that seems pretty intelligent) concerning one of my main disappointments in the 'rest' approach to web services. That is, the rest approach only encapsulates five possible behaviors (corresponding to the five HTTP verbs). In my mind, any other behavior encapsulation doesn't fit in the rest model. This guy disagrees...and he does so fairly eloquently....
http://www.xent.com/pipermail/fork/2001-August/002923.html
Unfortunately, this doesn't cut it for me - because, you're still not encapsulating any new behavior - your factoring it out into its crud operations, and then doing the behavior in the client code. So - it appears to me that rest is just not really suited to situations where you're actually trying to encapsulate behavior (such as non-trivial business logic)... but it is VERY nice for quickly modeling things that can be thought of as a resource or as a piece of data, that you want to be able to view or modify in a sort of low-level kind of way....this resource-centric approach is probably the best part of rest and would probably fit in well with other modes of web service delivery - but because of this short-coming - probably not a suitable replacement........at least IMHO. :)
Thursday, July 17, 2008
Tuesday, July 15, 2008
We're Not Resources
Why actually blog myself... when everyone else is saying everything.... here's a great post about how insulting and counter-productive it is to manage software engineers as if they were replaceable cogs....let's do like a commentor says, referring to people as "Resources" should be recognized as a bad word in polite, tasteful companies....
http://blog.markturansky.com/archives/95
http://blog.markturansky.com/archives/95
Monday, July 14, 2008
.NET Web App Cheat Sheet
Dude - all I have to say is 'Thank You'...
http://duartes.org/gustavo/articles/Asp.net-Runtime-Cheat-Sheet-HttpRequest-HttpRuntime.aspx
Tuesday, July 8, 2008
Code Monkey...
Cute song - definitely got to learn how to play it...
Here are the chords:
http://www.ultimate-guitar.com/tabs/j/jonathan_coulton/code_monkey_crd.htm
Here's a good music video for it:
http://www.youtube.com/watch?v=v4Wy7gRGgeA
Here are the chords:
http://www.ultimate-guitar.com/tabs/j/jonathan_coulton/code_monkey_crd.htm
Here's a good music video for it:
http://www.youtube.com/watch?v=v4Wy7gRGgeA
Thursday, July 3, 2008
Some .NET Hotness: Stack Traces
Check this link out...
http://neilkilbride.blogspot.com/2008/04/how-to-access-call-stack-c.html
Apparently it is possible to programmatically access the various portions of stack traces in C#/.NET -- this is neat, cause in the java world, last time I checked, you had to manually parse the stack trace generated by a Throwable in order to get any kind of an idea where you were in the call stack... so woo hoo -- give it up for MS - this is kinda hot!!
http://neilkilbride.blogspot.com/2008/04/how-to-access-call-stack-c.html
Apparently it is possible to programmatically access the various portions of stack traces in C#/.NET -- this is neat, cause in the java world, last time I checked, you had to manually parse the stack trace generated by a Throwable in order to get any kind of an idea where you were in the call stack... so woo hoo -- give it up for MS - this is kinda hot!!
Tuesday, July 1, 2008
Weekly Buzzword: Integration
Ah yes - integration - sounds greek, or latin, or something - sophisticated, no doubt. But what does it really mean?
Well, I would guess it means at least a couple of things.... going back to the theme about how software developers are rigid and talk, think, and dream in 1's and 0's - probably the simple answer would be - integration is just connecting to systems. It's like plugging a plug into a light socket - simple, straight forward - not a lot of room for interpretation.
Ok - let's go back to thinking like human beings again.....the above referenced analogy works.... insofar as you recognize that not only will you be plugging the two things in - you'll be inventing the light socket and the plug from scratch, with less than two napkins worth of drawings to help you along your quest...
So what does this mean in the real world? It means there are shades of grey, dummy. Integration isn't just connecting the two pieces it's fashioning the connectors - if you need to - or maybe reusing partially applicable connectors. At any rate - it's not black and white.
So we have a responsibility here - don't let non-technicals blow it off and say - oh yeah, we're just integrating.... make sure they (or you) think first. Inversely - don't let them say OH MY GOSH WE HAVE TO INTEGRATE - make sure they (or you) think first. After you think - then you have the right to casually blow it off or to get extremely apprehensive - whichever is appropriate.
In FACT - another action item could be taken from this week's buzzword: maybe we should design a few subclasses, revealing a little more information about the actual activity that is taking place in your "integration".
That is all.
Well, I would guess it means at least a couple of things.... going back to the theme about how software developers are rigid and talk, think, and dream in 1's and 0's - probably the simple answer would be - integration is just connecting to systems. It's like plugging a plug into a light socket - simple, straight forward - not a lot of room for interpretation.
Ok - let's go back to thinking like human beings again.....the above referenced analogy works.... insofar as you recognize that not only will you be plugging the two things in - you'll be inventing the light socket and the plug from scratch, with less than two napkins worth of drawings to help you along your quest...
So what does this mean in the real world? It means there are shades of grey, dummy. Integration isn't just connecting the two pieces it's fashioning the connectors - if you need to - or maybe reusing partially applicable connectors. At any rate - it's not black and white.
So we have a responsibility here - don't let non-technicals blow it off and say - oh yeah, we're just integrating.... make sure they (or you) think first. Inversely - don't let them say OH MY GOSH WE HAVE TO INTEGRATE - make sure they (or you) think first. After you think - then you have the right to casually blow it off or to get extremely apprehensive - whichever is appropriate.
In FACT - another action item could be taken from this week's buzzword: maybe we should design a few subclasses, revealing a little more information about the actual activity that is taking place in your "integration".
That is all.
Tuesday, June 24, 2008
Software Development Myth #2: "There are applications that don't need to be modular"
"My application doesn't need to be modular" means several things:
1) My application will never change, or will change so slowly that I will have plenty of time to make any and all changes.
Yeah right. Been coding long? Guess not.
Rapid change is accomodated by modularity - have it and you will be able to handle anything they throw at you.....neglect it, and you'll be neck deep in spaghetti with a red-faced manager screaming at you.
2) My application will never grow
Similar response as to number one - though this may not be quite as obvious to the noob - apps ALWAYS grow. Period. Unless the app just totally bites to begin with - system begets system. Whenever users actually get to use a system, it inspires them to want more system. Don't know how else to say it - but, if you build it, it will grow.
And if you build it monolithically - you're going to have to be reevaluating the entire app everytime you need to grow...not fun, and it definitely doesn't make you look like a rock star.
3) My application will never be maintained by anyone but me
Really? Nice. So you will NEVER leave this job. You will NEVER grow disinterested in maintaining the same code base year after year after year.... I don't know about you - but I'm usually bored immediately after it goes to production.....
The new maintainers will not be happy people if your code is a big monolithic mess.
4) My application will never be used for anything except what it was originally intended for
This one is funny - it's amazing how expectations change over the course of an application's lifetime. I wrote a system once that basically assumed (based on the existing business process) that only one person would be entering information at a time - and that the information would then be sent out and tracked to several hundred people. Unfortunately for the system - the organization grew by leaps and bounds - to the point that the business process started to parallelize - meaning more than one person would be entering information. Uh oh.
Because a user doesn't have your unique vision about the system, they will often use it in ways you never even thought of, let alone intended. If your application is not modular - you won't be able to accomodate this.
1) My application will never change, or will change so slowly that I will have plenty of time to make any and all changes.
Yeah right. Been coding long? Guess not.
Rapid change is accomodated by modularity - have it and you will be able to handle anything they throw at you.....neglect it, and you'll be neck deep in spaghetti with a red-faced manager screaming at you.
2) My application will never grow
Similar response as to number one - though this may not be quite as obvious to the noob - apps ALWAYS grow. Period. Unless the app just totally bites to begin with - system begets system. Whenever users actually get to use a system, it inspires them to want more system. Don't know how else to say it - but, if you build it, it will grow.
And if you build it monolithically - you're going to have to be reevaluating the entire app everytime you need to grow...not fun, and it definitely doesn't make you look like a rock star.
3) My application will never be maintained by anyone but me
Really? Nice. So you will NEVER leave this job. You will NEVER grow disinterested in maintaining the same code base year after year after year.... I don't know about you - but I'm usually bored immediately after it goes to production.....
The new maintainers will not be happy people if your code is a big monolithic mess.
4) My application will never be used for anything except what it was originally intended for
This one is funny - it's amazing how expectations change over the course of an application's lifetime. I wrote a system once that basically assumed (based on the existing business process) that only one person would be entering information at a time - and that the information would then be sent out and tracked to several hundred people. Unfortunately for the system - the organization grew by leaps and bounds - to the point that the business process started to parallelize - meaning more than one person would be entering information. Uh oh.
Because a user doesn't have your unique vision about the system, they will often use it in ways you never even thought of, let alone intended. If your application is not modular - you won't be able to accomodate this.
Subscribe to:
Posts (Atom)