I haven't been putting thought into this post so I thought I could at least post the things I have been thinking about and some resources. This is dealing with the use and idea of the code construct (C# interfaces). Feel free to comment with your own questions, answers, or resources.
what makes a good interface?
can you really refactor out to an interface?
if so how good would that interface really be?
how good did your class before hand have to be?
if not then it's important to consider interfaces up front
how do you make the judgement to put in the effort of making a good interface?
are these really just problems with explicit static typing instead of dynamic typing or inferred static typing?
how do you ensure the least astonishment with interfaces?
links for research:
http://blog.ploeh.dk/2010/12/02/InterfacesAreNotAbstractions.aspx
http://martinfowler.com/bliki/RoleInterface.html
http://simpleprogrammer.com/2010/11/02/back-to-basics-what-is-an-interface/
http://www.objectmentor.com/resources/articles/isp.pdf
http://www.lostechies.com/blogs/jimmy_bogard/archive/2010/12/02/the-case-against-interfaces-in-tdd.aspx
http://publicvoidlife.blogspot.com/2010/10/to-learn-is-to-abuse.html
http://en.wikipedia.org/wiki/Law_of_Demeter
http://en.wikipedia.org/wiki/Principle_of_least_astonishment
Nice post with some comments about the use of inheritance:
http://www.lostechies.com/blogs/derickbailey/archive/2011/01/18/i-use-inheritance-and-i-m-not-entirely-ashamed-of-it-should-i-be.aspx
Sunday, January 23, 2011
Saturday, January 15, 2011
Dear John
Following a tweet from @codinghorror, I just read a short article on why John C. Dvorak doesn't use Facebook. He outlines, in his own condescending old guy kind of way, how Facebook is just like AOL and how he didn't use it then and won't use it now. Really? John C. Dvorak is opinionated and wrong? Say it ain't so!
Well, to be fair, he's not wrong about the fact that he doesn't use Facebook (I'm assuming). And I'm sure his prediction that he won't use Facebook will continue to be true. (So he got one right.) But all of his reasoning in the matter is entirely invented. John, we don't need to you explain why you don't use a particular tool. We especially don't need you to just make stuff up about that tool to try to justify it to us. It all ends up sounding like a student's book report on a book he clearly hasn't read.
Let's address the main points of John's little rant. They are, in no particular order:
Yes, John, you can go make a webpage anywhere. You can set up a blog anywhere. You can even host your own services on your own server out of your house. The internet is wonderful like that. But Facebook isn't a service for a person to make a web page. It is, quite simply, a channel of communication. That's all, really. It's a way for people to talk to each other and easily share information with each other, either directly (by posting something directly to someone) or passively (by posting something which others can see, or choose not to see, etc.).
The personal home page thing was where MySpace fell flat. It all looked like crap. And it focused on the wrong aspect of the service. At first people wanted to put up their own pages, sure. But that was because they thought that's all they could do. Facebook took a different approach, and a radically successful one. It's not about the nodes of the network, it's about the connections between those nodes. A page, sitting out there on the internet by itself, is disconnected. Sure, people can read it and write on it, but it's disconnected. Facebook, as a tool, focused on the connections and facilitates the flow of information through those connections.
In short, it's not a personal web page. (Yes, there are "pages" mostly in the sense of a company's Facebook profile, etc.) Actually, and this should come as no surprise, I'm finding difficulty in articulating it. Maybe that's a testament to how ubiquitous Facebook has become in our society. Imagine trying to describe to somebody a concept that everybody already knows. It's actually quite difficult. But basically, Facebook isn't a blog or a homepage, it's just a tool for communication. I can easily see what all of my friends are up to, leave them a message, strike up a conversation, return to an old conversation, share some piece of media, etc. That's all, and that's all it needs. The tool provides all of this, and at its core is the benefit that it's the same tool that everybody uses. It's by no means perfect or immortal, but right now it's immensely useful.
Now, about the AOL keyword thing. Honestly, I would have thought that you could spot the difference. You've been using the internet for a long time now, John. I dare say, longer than I have. (Thanks for making me feel young and hip by the way, if only for a fleeting moment.) Yes, we all remember AOL. Those of us "with any chops online" (as you so condescendingly put it) all had a personal distaste for AOL. Sure, I used it back in the v2.5 and v3.0 days. It wasn't bad. It was cute. But it wasn't "the internet."
And, just like you, we all hated the whole "keyword" thing. Any time the nightly news anchor would direct the audience to "go to keyword blahblahblah" we would all die a little inside. But, you see John, the rest of us got over it. You seem to have been so burned by the keyword phenomenon (which was a long time ago, John) that you're still looking to release steam about it. To that end, you're just taking pot shots at the current big player, which is kind of childish.
The difference between keywords and Facebook pages is that the keywords were essentially meant to be a closed system within the AOL software. Maybe some of them actually led to external non-AOL resources (also known as web pages), I don't remember. But the system itself was a means of quickly navigating to some point within AOL's walled garden. Facebook pages, on the other hand, are nothing more than URLs. I do hope you know what a URL is. One doesn't need to be a part of some walled garden. One doesn't need a Facebook account at all. It's, get this, a web page on the internet.
Sure, within Facebook there is a little search bar where one can quickly find another Facebook page without needing the URL. That's called convenience, John. But the option is still there for anybody, with any web browser, and any affiliation or lack thereof with Facebook, to enter a URL (manually or by clicking a link) and be taken to a "Facebook page." That's the beauty of this here thing called the internet, John.
Speaking of the openness, what was that you said about Facebook being a closed system? Marketing departments the world over have piles of cash that disagree with you, John. I'm not going to go into a lot of details here (especially since I already wrote a post on the subject, which was already growing out of date by the time I finished writing it), but Facebook has capitalized on a huge source of revenue by explicitly making it very easy for an external site to integrate with Facebook services, and for a Facebook page to integrate with external resources.
Interoperability, John. It's the future. And it's happening right now. It all goes back to that concept that Facebook is about the connections, not about the nodes. The things that are interoperating, such as Facebook pages, non-Facebook pages, applications of all kinds all over the internet, etc. are just nodes. Facebook works to provide connections between those nodes. Sure, as a company it also makes it a point to track and monetize that flow of information. You don't get to be worth twenty five billion dollars by giving everything away for free. But the interoperability is by no means lacking.
In fact, you could even (and very easily) add a fairly small amount of code to your own personal site that would integrate it very well with Facebook. Share the information you want to share, track the information you want to track, etc. You don't need to "use Facebook" in the same way the average person does. It has an API. You can use your own site, and just integrate with Facebook's services.
This may not seem valuable to you, since you're already famous and people already listen to you. But for people who are less famous there's a certain value behind a tool that can quickly and easily expose them to a community of five hundred million people, where word of mouth spreads faster than through any communication channel in human history. (It's not unlike the Apple App Store in this sense. Stuffy old developers love to complain about Apple's walled garden, while young entrepreneurial developers line up at the door for a service that has an audience of millions and handles distribution and billing/collections for only 30% of the cut.)
John, you sound old and out of touch. Do you also refuse to use smart phones because you believe that a phone is just for phone calls and that's the way it should be? For someone who has made a career out of knowing the computer industry and talking about where it's going, you seem to be a solid decade behind the times on this one. You're a computer industry futurist living in the past.
No, Facebook isn't the end all answer to the internet. It's a tool. And it's a tool that has provided new things we didn't previously have or use nearly as commonly. It has changed how people interact. And even if it's already losing its popularity and already beginning its decline into the dark recesses of forgotten internet services, its impact is undeniable. Honestly, I'm surprised you missed it. That shot was heard 'round the world.
Now if you'll excuse me, I'm sure I have a lawn to get off of.
Well, to be fair, he's not wrong about the fact that he doesn't use Facebook (I'm assuming). And I'm sure his prediction that he won't use Facebook will continue to be true. (So he got one right.) But all of his reasoning in the matter is entirely invented. John, we don't need to you explain why you don't use a particular tool. We especially don't need you to just make stuff up about that tool to try to justify it to us. It all ends up sounding like a student's book report on a book he clearly hasn't read.
Let's address the main points of John's little rant. They are, in no particular order:
- Why make a personal home page on Facebook when I can make one somewhere else and have more control over it?
- Facebook pages are like AOL keywords.
- Facebook is a completely closed system.
Yes, John, you can go make a webpage anywhere. You can set up a blog anywhere. You can even host your own services on your own server out of your house. The internet is wonderful like that. But Facebook isn't a service for a person to make a web page. It is, quite simply, a channel of communication. That's all, really. It's a way for people to talk to each other and easily share information with each other, either directly (by posting something directly to someone) or passively (by posting something which others can see, or choose not to see, etc.).
The personal home page thing was where MySpace fell flat. It all looked like crap. And it focused on the wrong aspect of the service. At first people wanted to put up their own pages, sure. But that was because they thought that's all they could do. Facebook took a different approach, and a radically successful one. It's not about the nodes of the network, it's about the connections between those nodes. A page, sitting out there on the internet by itself, is disconnected. Sure, people can read it and write on it, but it's disconnected. Facebook, as a tool, focused on the connections and facilitates the flow of information through those connections.
In short, it's not a personal web page. (Yes, there are "pages" mostly in the sense of a company's Facebook profile, etc.) Actually, and this should come as no surprise, I'm finding difficulty in articulating it. Maybe that's a testament to how ubiquitous Facebook has become in our society. Imagine trying to describe to somebody a concept that everybody already knows. It's actually quite difficult. But basically, Facebook isn't a blog or a homepage, it's just a tool for communication. I can easily see what all of my friends are up to, leave them a message, strike up a conversation, return to an old conversation, share some piece of media, etc. That's all, and that's all it needs. The tool provides all of this, and at its core is the benefit that it's the same tool that everybody uses. It's by no means perfect or immortal, but right now it's immensely useful.
Now, about the AOL keyword thing. Honestly, I would have thought that you could spot the difference. You've been using the internet for a long time now, John. I dare say, longer than I have. (Thanks for making me feel young and hip by the way, if only for a fleeting moment.) Yes, we all remember AOL. Those of us "with any chops online" (as you so condescendingly put it) all had a personal distaste for AOL. Sure, I used it back in the v2.5 and v3.0 days. It wasn't bad. It was cute. But it wasn't "the internet."
And, just like you, we all hated the whole "keyword" thing. Any time the nightly news anchor would direct the audience to "go to keyword blahblahblah" we would all die a little inside. But, you see John, the rest of us got over it. You seem to have been so burned by the keyword phenomenon (which was a long time ago, John) that you're still looking to release steam about it. To that end, you're just taking pot shots at the current big player, which is kind of childish.
The difference between keywords and Facebook pages is that the keywords were essentially meant to be a closed system within the AOL software. Maybe some of them actually led to external non-AOL resources (also known as web pages), I don't remember. But the system itself was a means of quickly navigating to some point within AOL's walled garden. Facebook pages, on the other hand, are nothing more than URLs. I do hope you know what a URL is. One doesn't need to be a part of some walled garden. One doesn't need a Facebook account at all. It's, get this, a web page on the internet.
Sure, within Facebook there is a little search bar where one can quickly find another Facebook page without needing the URL. That's called convenience, John. But the option is still there for anybody, with any web browser, and any affiliation or lack thereof with Facebook, to enter a URL (manually or by clicking a link) and be taken to a "Facebook page." That's the beauty of this here thing called the internet, John.
Speaking of the openness, what was that you said about Facebook being a closed system? Marketing departments the world over have piles of cash that disagree with you, John. I'm not going to go into a lot of details here (especially since I already wrote a post on the subject, which was already growing out of date by the time I finished writing it), but Facebook has capitalized on a huge source of revenue by explicitly making it very easy for an external site to integrate with Facebook services, and for a Facebook page to integrate with external resources.
Interoperability, John. It's the future. And it's happening right now. It all goes back to that concept that Facebook is about the connections, not about the nodes. The things that are interoperating, such as Facebook pages, non-Facebook pages, applications of all kinds all over the internet, etc. are just nodes. Facebook works to provide connections between those nodes. Sure, as a company it also makes it a point to track and monetize that flow of information. You don't get to be worth twenty five billion dollars by giving everything away for free. But the interoperability is by no means lacking.
In fact, you could even (and very easily) add a fairly small amount of code to your own personal site that would integrate it very well with Facebook. Share the information you want to share, track the information you want to track, etc. You don't need to "use Facebook" in the same way the average person does. It has an API. You can use your own site, and just integrate with Facebook's services.
This may not seem valuable to you, since you're already famous and people already listen to you. But for people who are less famous there's a certain value behind a tool that can quickly and easily expose them to a community of five hundred million people, where word of mouth spreads faster than through any communication channel in human history. (It's not unlike the Apple App Store in this sense. Stuffy old developers love to complain about Apple's walled garden, while young entrepreneurial developers line up at the door for a service that has an audience of millions and handles distribution and billing/collections for only 30% of the cut.)
John, you sound old and out of touch. Do you also refuse to use smart phones because you believe that a phone is just for phone calls and that's the way it should be? For someone who has made a career out of knowing the computer industry and talking about where it's going, you seem to be a solid decade behind the times on this one. You're a computer industry futurist living in the past.
No, Facebook isn't the end all answer to the internet. It's a tool. And it's a tool that has provided new things we didn't previously have or use nearly as commonly. It has changed how people interact. And even if it's already losing its popularity and already beginning its decline into the dark recesses of forgotten internet services, its impact is undeniable. Honestly, I'm surprised you missed it. That shot was heard 'round the world.
Now if you'll excuse me, I'm sure I have a lawn to get off of.
Tuesday, January 11, 2011
CouchDB in the middle?
I have been discussing JavaScript applications with my friend Bryan and naturally we ended up agreeing that Node.js is a technology that simply can't be ignored. I think we are both going to end up playing around with it and deciding where it fits in with how we want to write web applications.
Node.js (Express.js is a simple web framework for it) seems like a nice replacement for say... Python or Java for your middle layer. So:
That would mean you still need some random implementation of a b-tree in a file so your application can remember things. JavaScript on the front end, JavaScript in the middle, why not JavaScript in the backend. This seems perfectly reasonable:
Ah CouchDB, the JavaScript friendly database. TO THE GOOGLE!
I came across this quite nice presentation from Js Conf discussing node.js and couchdb. It has a title you can't refuse: node.js + couchdb = Crazy Delicious. A formula only rivaled by Red Vines and Mr. Pibb. Anyway, this video hit me with this little number:
That's right node.js as your backend and your database as your middle. *starts twitching* Now it seems couchdb is sort of designed for this scenario with a create concurrent connection story, the ability to render html templates, and some kind of built in user security/session model. Also couchdb only speaks HTTP through a REST api. Quite the nice fit for interfacing with web clients it seems, but there are some bumps in this road. Couchdb is a bit of a sandbox.
It seems this model works by node.js listening on the _changes api from couchdb so that it can perform things that require sending e-mails, integrating with external services, manipulating multiple documents; things like that. How intriquing and unconventional.
This _changes api seems to allow for polling for updates since a previous one, long polling to get an single update when it happens, or a continuous streaming of updates as they happen. You can also implement filters for these so you get what you want. Pretty sexy sounding actually.
Node.js (Express.js is a simple web framework for it) seems like a nice replacement for say... Python or Java for your middle layer. So:
That would mean you still need some random implementation of a b-tree in a file so your application can remember things. JavaScript on the front end, JavaScript in the middle, why not JavaScript in the backend. This seems perfectly reasonable:
Ah CouchDB, the JavaScript friendly database. TO THE GOOGLE!
I came across this quite nice presentation from Js Conf discussing node.js and couchdb. It has a title you can't refuse: node.js + couchdb = Crazy Delicious. A formula only rivaled by Red Vines and Mr. Pibb. Anyway, this video hit me with this little number:
That's right node.js as your backend and your database as your middle. *starts twitching* Now it seems couchdb is sort of designed for this scenario with a create concurrent connection story, the ability to render html templates, and some kind of built in user security/session model. Also couchdb only speaks HTTP through a REST api. Quite the nice fit for interfacing with web clients it seems, but there are some bumps in this road. Couchdb is a bit of a sandbox.
It seems this model works by node.js listening on the _changes api from couchdb so that it can perform things that require sending e-mails, integrating with external services, manipulating multiple documents; things like that. How intriquing and unconventional.
This _changes api seems to allow for polling for updates since a previous one, long polling to get an single update when it happens, or a continuous streaming of updates as they happen. You can also implement filters for these so you get what you want. Pretty sexy sounding actually.
Node.js as a backend must mean a couple of things (I think). First thing that comes to mind is you could design a system that triggers events off of it's logging. So you log that the user wants to send an e-mail, then node.js picks that up, sends it, updates the document as sent. I'm not sure if that is a good design. It's interesting to think you log what you want to do, then it happens. The client just does a poll for that update and notifies the user it's complete.
Second thing that comes to mind is that you have to design your system around being asynchronous. The client code would write/update the documents, node.js would pick it up, perform the action, update the database. To my knowledge you couldn't do that synchronously. This is probably an advantage that you are forced into this.
Anyone think of some strange scenarios to show disadvantages of this scenario? In the "enterprise" world we seem to be moving towards message passing and message queuing... basically an asynchronous world.
The simple idea of CouchDB with a Node.js backend hit me pretty good. I want to explore this idea some more and hope to write a little project. Maybe a custom single social posting app thing. Post it once in my database then node.js picks it up and posts it to my Facebook, Twitter, maybe something else. Then have node.js pick up replies/comments and post them back into the database for a single social global view.
Sunday, January 9, 2011
The Right Tool For The Job
I just finished reading Davy Brion's latest blog post, entitled "Learning To Work With The Web, Instead Of Against It." It's one thing to say that I agree with his point, which I wholeheartedly do, but it's another entirely to continue the point and take it in hopefully a relevant, albeit tangential, direction.
Lately I've been on something of a crusade on "using the right tool for the job." It's becoming sort of my mantra for software craftsmanship. The idea is that the tool is less important than the craftsman. It's more important for a developer to perform a job well and produce a well-crafted product than it is for a developer to produce a product that fits within some contrived notion of what that developer should be doing. I often sum up this idea by saying, "It's better to be a developer who knows .NET than to be a .NET developer."
Now as you may already know, I am a web developer by trade. I specifically develop enterprise web applications on the .NET platform. I've been doing it for a while now, and I like to think I'm pretty good at it. You may also know that I look back on web forms with a kind of shame. Sean, you know what I'm talking about. It got the job done, sure. But was it the right tool for the job? Was it the right approach?
Davy touched on this a good bit in his post. The age of web forms is by no means over (at least not in the more stuffy and slow-to-progress corporate environments). But the ASP .NET community has poked its head above the water enough now to at least look around and see what else has been going on, and to get a more high-level view of web forms and what it really was. It was the wrong abstraction. (It looked like a duck, quacked like a duck, but needed batteries.)
Web forms represented a fight against the "web way of doing things" and an attempt to push that under enough code (using the dreaded "pluggable widget model," my arch nemesis in software craftsmanship) that developers wouldn't need to worry about all that web stuff and could just focus on good old rapid application development. And, as Davy pointed out, what did this lead to? Too many post-backs, slow load times, poor web software in general. It was a web platform that actively fought against the nature of the web, attempting to obscure and deny the very foundation of what it was doing.
Now, in the past year I've held four different jobs. Career-wise, it's been an interesting ride. But it's given me an opportunity to work with a lot of different people in various corporate cultures and learn a lot about how corporate developers can think and work. And I hate to say it, but a lot of times the focus is incorrectly placed on the tool rather than on the craftsman. And the tool in question at the moment is ASP .NET.
There's an old saying, "Nobody ever got fired for buying Microsoft." And since Microsoft is in the business of building and selling tools, this kind of mentality has led to too much focus on the tools and not enough on the craftsmen. No, I don't have any Microsoft certifications. No, I'm not a Microsoft MVP. I'm not interested in those things. I see no value in them. (If you do see value in them, then by all means go ahead and use them. Value is relative, it's all in the perception. So don't think that I'm somehow de-valuing your own expertise for the sake of my own, because I'm not.)
The point that I'm getting at is that I've seen a good number of developers who cling to ASP .NET as a kind of catch-all tool that can be used to address all of the requirements they face. And, even worse, they maintain a very narrow view of what ASP .NET can do for them. If it's in an MSDN tutorial somewhere, or on a ScottGu blog post somewhere, then it must be right because it's the Microsoft way of doing things. It's safe. It's the tool we use, and we must obey the tool.
Unfortunately, this has led to a whole industry of "web developers" who know little if anything about HTML, CSS and JavaScript. These are the core components of web development today. Everything you present to the user in ASP .NET gets translated into these technologies. But the tool does everything it can to hide that fact from the developers, and thus the developers remain blissfully unaware of it.
In my travels this past year (not just at work, but also in helping people on Stack Overflow), I've heard such interesting (and frightening) statements made by web developers as (paraphrased):
Well, just take a look at Google's products and how they're crafted. They don't do anything "the Microsoft way" or "the Sun way" or "the Oracle way" or any other way. They do things "the Google way" and, by that, they do everything they can to use the right tool for the job and use it well. Rather than pick a tool and try to fit all of their requirements into the skill set of that tool, they use whatever tools are at their disposal. They even make their own, if the need arises. In developing on the web as a platform, they have demonstrated beautifully the importance of this. They have embraced the tools of the web.
Look at Google Maps as an example. Let's say your company wanted to build something like that. Could you build it in ASP .NET with Microsoft's pluggable widgets? (Well, you'd use some Bing stuff instead of some Google stuff, but you get the idea.) Sure. Would it be as sleek and polished and well-received as Google Maps? Not a chance. Your ASP .NET map site, though it uses the approved and well-established tool(s) you love, wouldn't be using web technologies properly in this particular case. All the functionality may be there, but the user experience would be kludgy at best.
Google employs a lot of JavaScript in a product like that. Plain old JavaScript. That same language you used twelve years ago to make text-box-based tic-tac-toe games in your browser, or to make little swinging tails that follow the cursor, or to make a scrolling marquee in the browser's status bar. But they didn't just use it, they embraced it. They didn't just write code that happened to be in JavaScript, they embraced a fundamental understanding of what web development is and how it works and where JavaScript fits into that.
For every ASP .NET developer I've seen avoid JavaScript, I've also seen one who "uses" it, by which I mean they copy/paste somebody else's JavaScript code onto their page in order to accomplish something. You know what that is? It's a pluggable widget. It's a block of code that the developer didn't write, and more importantly doesn't understand, but somebody said it'll work and it seems to get the job done so they go ahead and use it. (I'll admit it, I've done this many times in the past. But no more.) Sure, it's JavaScript, but it's not the tool that matters. It's how you're using it. You're using that JavaScript like any other ASP .NET web forms control. You drag it onto the page and forget about it. You don't know (or even care) how it actually works and what it actually does. In other words, you're still denying the very nature of web development while you are engaged in web development.
How do you think Google's products would work if they did that same thing? It would be a mess. So, to answer those business users who want to know why their development teams can't do this, it's because their development aren't embracing web development properly. They're trying to fit the web into their toolbox, rather than expanding their toolbox to embrace the web. You can't change how the web works. Honestly. New things come along, sure. But you're still talking about HTML, CSS and JavaScript on the client side and some back-end technology on the server. You're still talking about a stateless request/response model. There are abstractions to this, some more successful or useful than others, but you have to embrace the fundamentals of the platform itself. You can't abstract yourself away from the very foundation of what it is you're doing.
Davy's last paragraph was short and simple, and just a touch of inspirational:
The web as a platform (I still don't like that term for some reason. I need to figure out why.) is rich, engaging and strong. And web development is, at least for me, interesting and fun. So stop hiding behind your tools. Stop clinging to the software development model that Microsoft has tried to force upon you. Keep in mind the market forces behind a lot of Microsoft's decisions. When ASP .NET first came out, Microsoft was pitiful for web development. They designed it in part to allow VB6 and COM developers to be able to jump on the web bandwagon. Don't get me wrong, ASP .NET has come a long way and I love a lot of what the community has produced. But the old cruft is still there. Scrape off that cruft, and embrace web development.
P.S. I would like to point out that some of the people I've worked with in the past year are not the ones I'm talking about/to in this post. For the most part, you all know who you are. Some of you have in fact been a point of much inspiration for my work. Sean and John are the most relevant examples of this.
Lately I've been on something of a crusade on "using the right tool for the job." It's becoming sort of my mantra for software craftsmanship. The idea is that the tool is less important than the craftsman. It's more important for a developer to perform a job well and produce a well-crafted product than it is for a developer to produce a product that fits within some contrived notion of what that developer should be doing. I often sum up this idea by saying, "It's better to be a developer who knows .NET than to be a .NET developer."
Now as you may already know, I am a web developer by trade. I specifically develop enterprise web applications on the .NET platform. I've been doing it for a while now, and I like to think I'm pretty good at it. You may also know that I look back on web forms with a kind of shame. Sean, you know what I'm talking about. It got the job done, sure. But was it the right tool for the job? Was it the right approach?
Davy touched on this a good bit in his post. The age of web forms is by no means over (at least not in the more stuffy and slow-to-progress corporate environments). But the ASP .NET community has poked its head above the water enough now to at least look around and see what else has been going on, and to get a more high-level view of web forms and what it really was. It was the wrong abstraction. (It looked like a duck, quacked like a duck, but needed batteries.)
Web forms represented a fight against the "web way of doing things" and an attempt to push that under enough code (using the dreaded "pluggable widget model," my arch nemesis in software craftsmanship) that developers wouldn't need to worry about all that web stuff and could just focus on good old rapid application development. And, as Davy pointed out, what did this lead to? Too many post-backs, slow load times, poor web software in general. It was a web platform that actively fought against the nature of the web, attempting to obscure and deny the very foundation of what it was doing.
Now, in the past year I've held four different jobs. Career-wise, it's been an interesting ride. But it's given me an opportunity to work with a lot of different people in various corporate cultures and learn a lot about how corporate developers can think and work. And I hate to say it, but a lot of times the focus is incorrectly placed on the tool rather than on the craftsman. And the tool in question at the moment is ASP .NET.
There's an old saying, "Nobody ever got fired for buying Microsoft." And since Microsoft is in the business of building and selling tools, this kind of mentality has led to too much focus on the tools and not enough on the craftsmen. No, I don't have any Microsoft certifications. No, I'm not a Microsoft MVP. I'm not interested in those things. I see no value in them. (If you do see value in them, then by all means go ahead and use them. Value is relative, it's all in the perception. So don't think that I'm somehow de-valuing your own expertise for the sake of my own, because I'm not.)
The point that I'm getting at is that I've seen a good number of developers who cling to ASP .NET as a kind of catch-all tool that can be used to address all of the requirements they face. And, even worse, they maintain a very narrow view of what ASP .NET can do for them. If it's in an MSDN tutorial somewhere, or on a ScottGu blog post somewhere, then it must be right because it's the Microsoft way of doing things. It's safe. It's the tool we use, and we must obey the tool.
Unfortunately, this has led to a whole industry of "web developers" who know little if anything about HTML, CSS and JavaScript. These are the core components of web development today. Everything you present to the user in ASP .NET gets translated into these technologies. But the tool does everything it can to hide that fact from the developers, and thus the developers remain blissfully unaware of it.
In my travels this past year (not just at work, but also in helping people on Stack Overflow), I've heard such interesting (and frightening) statements made by web developers as (paraphrased):
- "I don't know JavaScript, so I can't support that. Write it in .NET instead."
- "Why should I use CSS? I can just set the properties on the controls."
- "What do you mean there are too many post-backs? How else is it going to use the code?" ("The code" in this case was simple string manipulation in the UI, nothing more.)
- "Why didn't you convert this HTML to .NET? Isn't the site written in .NET?"
- "We can't use Rake, everything we do has to be done from within Visual Studio."
- etc.
Well, just take a look at Google's products and how they're crafted. They don't do anything "the Microsoft way" or "the Sun way" or "the Oracle way" or any other way. They do things "the Google way" and, by that, they do everything they can to use the right tool for the job and use it well. Rather than pick a tool and try to fit all of their requirements into the skill set of that tool, they use whatever tools are at their disposal. They even make their own, if the need arises. In developing on the web as a platform, they have demonstrated beautifully the importance of this. They have embraced the tools of the web.
Look at Google Maps as an example. Let's say your company wanted to build something like that. Could you build it in ASP .NET with Microsoft's pluggable widgets? (Well, you'd use some Bing stuff instead of some Google stuff, but you get the idea.) Sure. Would it be as sleek and polished and well-received as Google Maps? Not a chance. Your ASP .NET map site, though it uses the approved and well-established tool(s) you love, wouldn't be using web technologies properly in this particular case. All the functionality may be there, but the user experience would be kludgy at best.
Google employs a lot of JavaScript in a product like that. Plain old JavaScript. That same language you used twelve years ago to make text-box-based tic-tac-toe games in your browser, or to make little swinging tails that follow the cursor, or to make a scrolling marquee in the browser's status bar. But they didn't just use it, they embraced it. They didn't just write code that happened to be in JavaScript, they embraced a fundamental understanding of what web development is and how it works and where JavaScript fits into that.
For every ASP .NET developer I've seen avoid JavaScript, I've also seen one who "uses" it, by which I mean they copy/paste somebody else's JavaScript code onto their page in order to accomplish something. You know what that is? It's a pluggable widget. It's a block of code that the developer didn't write, and more importantly doesn't understand, but somebody said it'll work and it seems to get the job done so they go ahead and use it. (I'll admit it, I've done this many times in the past. But no more.) Sure, it's JavaScript, but it's not the tool that matters. It's how you're using it. You're using that JavaScript like any other ASP .NET web forms control. You drag it onto the page and forget about it. You don't know (or even care) how it actually works and what it actually does. In other words, you're still denying the very nature of web development while you are engaged in web development.
How do you think Google's products would work if they did that same thing? It would be a mess. So, to answer those business users who want to know why their development teams can't do this, it's because their development aren't embracing web development properly. They're trying to fit the web into their toolbox, rather than expanding their toolbox to embrace the web. You can't change how the web works. Honestly. New things come along, sure. But you're still talking about HTML, CSS and JavaScript on the client side and some back-end technology on the server. You're still talking about a stateless request/response model. There are abstractions to this, some more successful or useful than others, but you have to embrace the fundamentals of the platform itself. You can't abstract yourself away from the very foundation of what it is you're doing.
Davy's last paragraph was short and simple, and just a touch of inspirational:
I don’t know what you will do, but i know what i’m going to do. I’m going to learn how to work with the web instead of against it. I’m finally going learn HTML. I’m going to learn CSS. I’m going to learn JavaScript. I’m going to learn about REST. And i’m going to be using that knowledge years from now as i follow the further evolution of the web.I wish more developers would espouse that kind of attitude. Replace "I don't know JavaScript so I can't support that" with "I should learn JavaScript so I can better support, or even better create, web applications." I'm still learning too, Davy. My HTML is pretty strong, my JavaScript is getting better all the time, my CSS is limited by my poor graphical layout and design skills. (I'm one of those people who just tinkers with the CSS unit it works, rather than actually writes it from the start with a real plan and a real understanding of the tool. At least for now.)
The web as a platform (I still don't like that term for some reason. I need to figure out why.) is rich, engaging and strong. And web development is, at least for me, interesting and fun. So stop hiding behind your tools. Stop clinging to the software development model that Microsoft has tried to force upon you. Keep in mind the market forces behind a lot of Microsoft's decisions. When ASP .NET first came out, Microsoft was pitiful for web development. They designed it in part to allow VB6 and COM developers to be able to jump on the web bandwagon. Don't get me wrong, ASP .NET has come a long way and I love a lot of what the community has produced. But the old cruft is still there. Scrape off that cruft, and embrace web development.
P.S. I would like to point out that some of the people I've worked with in the past year are not the ones I'm talking about/to in this post. For the most part, you all know who you are. Some of you have in fact been a point of much inspiration for my work. Sean and John are the most relevant examples of this.
Friday, January 7, 2011
On PDFs
Microsoft is ubiquitous. PDFs are ubiquitous. So why the hell don't the two get along?
For those of you keeping score... It's 2011, I'm running the latest and greatest Windows, and I still need to hunt around for some damn third party tool just to print to a PDF file. I don't care if MS Office can write to a PDF. I don't open everything in MS Office. (If I had my way, I wouldn't open anything in MS Office.) It should be integrated with the print system. You have no excuses.
Yes, I know I can print to an XPS file. I can even print to a TIFF using the "Microsoft Office Document Image Writer" (sounds fancy, doesn't it?). But nobody, nobody wants to do either of those things.
For those of you keeping score... It's 2011, I'm running the latest and greatest Windows, and I still need to hunt around for some damn third party tool just to print to a PDF file. I don't care if MS Office can write to a PDF. I don't open everything in MS Office. (If I had my way, I wouldn't open anything in MS Office.) It should be integrated with the print system. You have no excuses.
Yes, I know I can print to an XPS file. I can even print to a TIFF using the "Microsoft Office Document Image Writer" (sounds fancy, doesn't it?). But nobody, nobody wants to do either of those things.
Tuesday, January 4, 2011
Quick and Easy Facebook Integration
I figured I'd take a break from the soapbox-style posts I often write and take a step back to another of the original ideas regarding this blog... Sharing something quick and easy and potentially cool to do in code. This one comes inspired by a handful of Stack Overflow questions I've answered on the subject, and may indeed serve as a simple place to point users to if they ask more similar questions in the future (unless, of course, it's an actual duplicate question and can just be referred to the previous question, as is the SO way).
Facebook development and integration is nothing new. Come on, man, everybody's doing it. Don't you want to be cool? Indeed, while I'm sure that a lot of people/companies are doing this, and while it's evident that a lot of them meet with a great deal of success in the matter, my experience as of late seems to indicate that many people/companies toy with the idea but have no clue as to how to actually implement it. Well, product folks can undoubtedly come up with all the marketable and sellable ideas they want in this matter, but success or failure may hinge on the simple idea of know how the Facebook platform actually works. It's one thing to say "we need more Facebook on our site!" and it's another thing entirely to come up with an actual workable solution.
To that end, let's take a look at some very basic Facebook integration. You may or may not have heard of their Graph API, which is basically a JSON service for getting information our of their "social graph" (the various data objects they track and the relationships between them). Getting that data, once you have permission that is, is actually very simple.
First, you need to create your application on Facebook. (This step is a lot easier than it sounds.) Basically, give Facebook some simple information about your website and how it'll be integrating. Start out with something simple:
Facebook has some restrictions on the format of the Site URL, I usually just give it a folder where I'll be putting my Facebook-ish stuff on the site. The page you ultimately want to reach in this process is this one:
Congratulations, you now have a "Facebook app." Now what are you going to do with it? Well, keep in mind again that the approach I'm taking here is for interfacing with the Facebook Graph API from your website. You know, visitors come to your site, they use their Facebook account (since they're most likely logged into Facebook in another tab) to "Like" your site, you harvest their data and spam their friends, etc.
So now you need to add some Facebook stuff to your site. Note the sample code in the preceding screen shot above. This code does a couple things:
Next, the login button. This is using FBML, which will be handled by their JavaScript code and translated into what it needs to be on the page. You can create mildly a customized login with a few given parameter, but the basic thing you need to do here is ask the user for permission to access their Facebook data. Take a look at the "Login" section of this page (recently updated). The simplest approach, which is what we're doing here, is to ask the user for some permission to their data. This is done by decorating the FBML login tag with some permission request modifiers.
This is where the user grants or denies your site access to their Facebook data. If they deny you, then your work ends here. But if they allow you to access the data, then this is where you'll be able to send requests to Facebook on their behalf. You can go so far as to, if permitted, post stuff to their wall or send messages to their friends, etc. But, again, we're sticking with the basics here. We want to see the Graph API data.
Once permission is granted, Facebook writes a cookie to the user's computer which you can use. Remember that "application secret" value from before? You use that to decrypt the cookie. Take a look at this PHP code (which can still be found here, though they change their documentation a lot):
Notice how it's using the application secret string to decrypt the user's cookie, and from that cookie pull a critical piece of information... the access token.
(Note: You must never share your application secret with anybody. Don't render it to the page, don't use it anywhere but your protected server-side code. Anybody who has this value can pretend to be your application and can spoof users and Facebook as you. The access token you pull form a user's cookie should also be treated with this level of secrecy, with one exception. You can render that to the page, since you're pulling it from the user's cookie and just showing it back to the user. However, proper use of SSL is, as always, recommended.)
Note how the PHP code then makes a simple Graph API request to get the user's name. In this case, the "me" in the Graph API URL is being interpreted by Facebook as the user who owns the access token. There are a number of ways to access a particular user's node on the graph, this is just one of the shortcuts. But basically, this is what you're looking for.
These Graph API requests are just URLs with query string parameters, and they just return JSON. (The data structure is generally fields of data with the occasional object field which has its own ID and can be requested as its own node on the graph.) So the requests can just as easily be made from your JavaScript code on the client-side or your server-side code. Each has their advantages and disadvantages (I prefer to do as much in the JavaScript code as possible in this case):
Keep in mind that the Facebook documentation changes all the time. They're known to have broken internal links, pages which link to themselves, etc. But there is a lot there. Once you're started with something as simple as the above example, the learning curve flattens considerably and you can branch out a lot through their FBML, JavaScript, and Graph integration options.
Facebook development and integration is nothing new. Come on, man, everybody's doing it. Don't you want to be cool? Indeed, while I'm sure that a lot of people/companies are doing this, and while it's evident that a lot of them meet with a great deal of success in the matter, my experience as of late seems to indicate that many people/companies toy with the idea but have no clue as to how to actually implement it. Well, product folks can undoubtedly come up with all the marketable and sellable ideas they want in this matter, but success or failure may hinge on the simple idea of know how the Facebook platform actually works. It's one thing to say "we need more Facebook on our site!" and it's another thing entirely to come up with an actual workable solution.
To that end, let's take a look at some very basic Facebook integration. You may or may not have heard of their Graph API, which is basically a JSON service for getting information our of their "social graph" (the various data objects they track and the relationships between them). Getting that data, once you have permission that is, is actually very simple.
First, you need to create your application on Facebook. (This step is a lot easier than it sounds.) Basically, give Facebook some simple information about your website and how it'll be integrating. Start out with something simple:
So now you need to add some Facebook stuff to your site. Note the sample code in the preceding screen shot above. This code does a couple things:
- Initialize your page with your Facebook app.
- Present the user with a Facebook login button.
- Present the user with a Facebook "like" button.
Next, the login button. This is using FBML, which will be handled by their JavaScript code and translated into what it needs to be on the page. You can create mildly a customized login with a few given parameter, but the basic thing you need to do here is ask the user for permission to access their Facebook data. Take a look at the "Login" section of this page (recently updated). The simplest approach, which is what we're doing here, is to ask the user for some permission to their data. This is done by decorating the FBML login tag with some permission request modifiers.
This is where the user grants or denies your site access to their Facebook data. If they deny you, then your work ends here. But if they allow you to access the data, then this is where you'll be able to send requests to Facebook on their behalf. You can go so far as to, if permitted, post stuff to their wall or send messages to their friends, etc. But, again, we're sticking with the basics here. We want to see the Graph API data.
Once permission is granted, Facebook writes a cookie to the user's computer which you can use. Remember that "application secret" value from before? You use that to decrypt the cookie. Take a look at this PHP code (which can still be found here, though they change their documentation a lot):
(Note: You must never share your application secret with anybody. Don't render it to the page, don't use it anywhere but your protected server-side code. Anybody who has this value can pretend to be your application and can spoof users and Facebook as you. The access token you pull form a user's cookie should also be treated with this level of secrecy, with one exception. You can render that to the page, since you're pulling it from the user's cookie and just showing it back to the user. However, proper use of SSL is, as always, recommended.)
Note how the PHP code then makes a simple Graph API request to get the user's name. In this case, the "me" in the Graph API URL is being interpreted by Facebook as the user who owns the access token. There are a number of ways to access a particular user's node on the graph, this is just one of the shortcuts. But basically, this is what you're looking for.
These Graph API requests are just URLs with query string parameters, and they just return JSON. (The data structure is generally fields of data with the occasional object field which has its own ID and can be requested as its own node on the graph.) So the requests can just as easily be made from your JavaScript code on the client-side or your server-side code. Each has their advantages and disadvantages (I prefer to do as much in the JavaScript code as possible in this case):
- Client-Side: You offload some of the work to the client's machine. The performance implications here are obvious, but for me the main one is that the client's browser is probably better suited for multiple parallel requests than your server code. Let it handle it. Otherwise, you risk have your client sitting and waiting, even if just for a moment or two, while you make requests on their behalf. Just do it in JavaScript and let their browser handle it. Also, one big thing to note here is that you can tell your users that their data never actually touches your server. It's all from Facebook, you never see it. People like privacy policies that can make claims like that.
- Server-Side: Once you have that access token, you can continue to make requests for data on their behalf. So in an offline process you can start harvesting. (Yes, it pains me to say that. Let me explain...) You can, say, loop through their friends list and grab email addresses (assuming their friends allow that, they have privacy settings too) to compare with your local data store. Then you can prompt the user with such gems as "I see your friends are already members of this site, would you like to say hello?" or "Your friends haven't signed up for this site, click here to invite them." And so on. Act responsibly, of course. The user trusts you with their data, don't betray that.
Keep in mind that the Facebook documentation changes all the time. They're known to have broken internal links, pages which link to themselves, etc. But there is a lot there. Once you're started with something as simple as the above example, the learning curve flattens considerably and you can branch out a lot through their FBML, JavaScript, and Graph integration options.
Subscribe to:
Posts (Atom)