Rants Tagged with “Programming”
1 2 3 4 5 6 > >> (Total Pages: 6/Total Results: 59)
If you haven't read Part 1 yet, you can read it here.
After spending time creating my own caches of reflection data I found the NHibernate type information to be more complete and faster. Go figure. At this point I am using the SessionFactory's GetClassMetadata and GetCollectionMetadata to return IClassMetadata and ICollectionMetadata interfaces. So far this has given me every piece of runtime information I need and means that I don't need to do any nasty (and potentially fragile) walking through the property interface of the context object. Whew...
So to refactor my GetResource and CreateResource calls. GetResource is easy. GetResource passes in the query and the full type name (though the full type name may be missing in some cases). The query it passes it must resolve to a single result. That means I can simply execute the the query and if it returns more or less than one result, return an error. Once I have the result I can just check it against the full type name (if it was passed in) and return the value.
CreateResource is a bit more complicated. The IClassMetadata allows me to call their Instantiate method to create a new instance of the class but the new instance is not initialized with any data. Most notably, the missing detail is a key. In the case of many entities, this is fine (e.g. if zero ID is a valid "new" entity). But in others the key needs to be specified. (Customer in the Northwind database is an example of this.) The problem is that we have to keep a reference to the new objects so that when ADO.NET Data Services asks us to set properties, get properties and save, we have to have the object in the Session. But we can't add it to the Session with an invalid key. What to do? My solution for now is a local cache of objects that are not ready to be saved (only really happens with newly created objects). When we are ready to save, we'll just add it to the Session then (when its either valid or we'll throw an exception because its invalid).
Now a quick mention of GetProperty and SetProperty. These are both pretty easy as the IClassMetadata includes a similar method to set and get properties. The only wrinkle is that if you try and set a key using the GetProperty/SetProperty, the keys are not in the list of properties. Because of this I just checked to see if the property is part of the key and set the key instead, if its not part of the key we can just set or get the property. Now that we have the basic part of the interface complete its down to the hard parts. But that's for the next part!
Ted Neward's blog is one of those blogs that *everyone* should read. I am always surprised when I hear of .NET guys who don't know him. I think because he's been firmly in all camps at the same time, he often gets dismissed for "being a Java guy". Too bad for you that don't know better. Subscribe today, read the backlog, learn and grow as a developer.
His post today espouses an opinion that I first saw in the Pragmatic Programmer, learn a new language every year. Read Ted's blog to understand why if you haven't heard this before as he explains it better than I can. I've been playing catch-up and trying out a lot of languages lately. Mostly F#, IronRuby, IronPython and Boo. I hear people talk about these languages as the new 'fix' for development and I can't really profess that I believe that but it does open up your expectations about how code is written. Ideas like immutability, duck typing, loose coupling and closures are all good ideas that are hard to see if you spend your day in a staticly typed language. Sure, coming from VBScript and JavaScript in ASP number of years ago, the idea of typeless/late bound make me crazy. But there are really good ideas here. Go experiment and play with a language, it opens up your mind to getting the job done. The only thing I really can't stand is white-space significance in Python...that's just plain wrong ;)
Now that the change to Wildermuth.com is complete I've gotten questions about broken links and such. I am keeping adoguy.com around and redirecting (permanent) the links so that old links aren't going to break. I don't plan on keeping it forever but for several years you can be sure. Its worth keeping them around.
I didn't just do a quick and dirty port to a new CSS look and feel though. This was a conversion of the old code. I don't use a blog engine but write my own code, mostly as a test bed for new ideas. What was it this time? Two thinks significant changed: Entity Framework/LINQ as the data access and the ASP.NET Routing Framework instead of .aspx links. Let's take these one at a time:
The use of the Entity Framework and LINQ was pretty straightforward. I used LLBLGen Pro in my old site to do the data access and it held up great. I only switched so I could test out the Entity Framework on a production-ish system. Not because of any limitations in the old code. Creating a model with the Entity Framework was a snap. My data is not complicated so I didn't have any complex scenarios. The only think I did do was change the collection names from singular to plural. Being able to use LINQ to do my queries, search and paging was just spectacularly useful. I am completely in the LINQ camp now.
The second testbed was the new ASP.NET Routing Framework . What is the ASP.NET Routing Framework you say? Many of you have heard of ASP.NET MVC. The ASP.NET Routing Framework is the code that does all the custom routing for MVC. The ASP.NET Routing Framework is going to be released with .NET 3.5 SP1, not part of MVC so its not expected to change nearly as much as I expect MVC to mature. In that light, I couldn't port my site to MVC wholly because of the limitations in ViewState and ControlState. I could have worked around these limitations but I wanted to be able to focus on the new pieces and not have to re-write every page of the application (or use client-side libraries). So I found the middle ground of the ASP.NET Routing Framework. I am using Phil Haack'd great WebFormRouting class to do much of the heavy work of not only routing to the pages but sending the same sort of context that I could have used with MVC. Its much better than digging into the Response variables IMHO. You will note that most of the pages are now tail-less (e.g. http://adoguy.com/rants.aspx is now http://wildermuth.com/rants) though the old tail'd versions still work for backwards compatibility. I was able to simple tail-less versions by using his class (note the 2nd one uses an optional URI part):
routes.Map("Search").To("~/Search.aspx");
routes.Map("Rants/{page}").To("~/Rants.aspx");
I also set up my Rant URI's like so:
routes.Map("{year}/{month}/{day}/{topic}.aspx").To("~/ViewRant.aspx");
routes.Map("{year}/{month}/{day}/{topic}").To("~/ViewRant.aspx");
There was a challenge I had that I wanted the tail-less URI's but I am hosted on Windows 2003 (which means IIS6). I bit the perf bullet though and mapped all requests through ASP.NET. This means that all requests are running through ASP.NET which can be slower but I thought it was worth the better URI model. IIS7 can do the tail-less URI's without having to resort to everything being a ASP.NET request. Here's a good article on setting up IIS6: http://biasecurities.com/blog/2008/how-to-enable-pretty-urls-with-asp-net-mvc-and-iis6/. You can also accomplish it with URL re-writing but if I wanted to do URL re-writing why'd I use the routing framework instead of re-writing them all?
Its been a fun exercise as well as a re-branding effort. I hope everyone likes the new site!
I have been diving pretty deep into ADO.NET Data Services (see an upcoming article about ADO.NET Data Services and Silverlight 2 coming soon). I've been looking at the story around non-Entity Framework models through a Data Service and thought that NHibernate through a Data Service would be a great example.
So I tried to get it to work with the NHibernate LINQ project. The example model that the project uses is a simple Northwind model. I thought I'd just take that model and expose it via ADO.NET Data Services. I crufted up a simple Data Context object for ADO.NET Data Model but it didn't work. ADO.NET Data Services was complaining about the fact that the end-points (e.g. IQueryable<Customer>) was pointing at an Entity. This was a bug...a but in ADO.NET Data Services. I hacked together a fix to get around it (and reporting it). If you're interest, the problem is that if the key of the entity is in a base class and *not* named "ID", it fails to find it. Again, this is a bug not a feature of ADO.NET Data Services.
Now that it was working, now what? I wanted to be able to make changes to the model but the NHibernate context doesn't support the updating interface: IUpdatable. (Though I sure wish they'd rename it IUpdateProvider to match the IExpandProvider interface). If you're not familiar with this requirement, note that only the Entity Framework currently support the IUpdatable interface (and is in fact implemented inside of ADO.NET Data Services not directly in Entity Framework). This means that DataSets and LINQ to SQL do not support it either.
That's where I went to the Rhino Google Group (the discussion point for this project) and offered to implement the IUpdatable for the NHibernate provider. I thought it would be a fun exercise to understand the guts of the ADO.NET Data Service stack.
My first chore was to attempt to find a solution to decouple System.Data.Services.dll from the rest of the LINQ provider. My reasoning for this is that ADO.NET Data Services requires .NET 3.5 SP1 and I didn't want to tie the changes to that version of the Framework. Interestingly this is the same tactic that the ADO.NET Data Services team took. This is why the Entity Framework does not implement the IUpdatable interface themselves, but the ADO.NET Data Service does it for them. For the rest of the world, it expects a IUpdatable implementation directly on the context object that is used as the starting point for the service. After running around a number of ideas and running it by the Rhino people, we've decided to table that problem and get the interface working. That will be a fight we fight later with a number of proposed solutions.
So now that architecture is out of the way, its time to start actually implementing the interface. For the first pass, I am going to implement IUpdatable directly on NHibernateContext and refactor it later for less tight coupling. While I am at it, I also want to add support for IExpandProvider so that we can do expansions through NHibernate.
After adding the interface to the context object, I looked through the interface (its about a dozen calls that need to be implemented) to determine where to start. I am starting with the simple calls (GetResource, CreateResource, DeleteResource). These calls are used by the service to do basic object manipulation.
For GetResource, I am handed a query and possibly a type name. GetResource is supposed to invoke the query to get the one and only one result (implementors should throw an error if the result returns more than one result) and then check the type name against the result. In some cases you won't get the type name, but in most cases you will need to verify that the type of the result is the same as the type name. This is used to make sure that derived types are correctly retrieved from the data provider.
In implementing CreateResource, I noticed that I needed to be able to look up type information. Type information is important as I need information about the containers (e.g. IQueryable endpoints) on the context object. This information is not readily available as its the classes that derive from NHibernate that add these end-points. I could get the type information via NHibernate's type information or using Reflection (neither are particularly cheap). For the first iteration I choose Reflection since I know that better, but I wanted to mitigate the cost with some caching. To that end, I've created some small in-memory caches of the reflection information that hopefully will help with the performance of these lookups. This type information will help act like a factory to create new instances of the object. Unlike other ORM's, NHibernate doesn't use factories but uses simple object creation so we can just use the reflection information to create the instance of the new object and attach it to the NHibernate ISession.
Lastly, the simplest of the three methods to implement is the DeleteResource as it passes in a query (again, should always only return a single result) and mark it deleted in the session. The change shouldn't be persisted (there is a SaveChanges call on the IQueryable interface that facilities the actual persistence to the data store).
Overall a fun couple of days. Now on to the rest of the interface. I'll keep you posted with my experience dealing with them!
Pete Brown called me out to answer the next round of "what about you" questionnaires floating around the blog-o-sphere. So here's my take:
How old were you when you first started programming?
I got a Vic-20 when I was ten and started pretty quickly into Commodore Basic. I voraciously read Compute magazine and can remember reading the programs in the back and hoping those data sections were typed right.
How did you get started in programming?
I would visit other geek friends and discuss Basic with them pretty freely through high-school. I remember programming a lot of 6510 machine language stuff (Poke and Peek in Commodore basic, one byte at a time). I tried it on the Apple ]['s at school too. It wasn't until I was sixteen that I got serious about how it really worked when I got a summer job learning and programming.
That first summer I was introduced to a CP/M variant called TurboDOS (a multi-user CP/M believe it or not) that ran on Wyse green screen terminals. I had to learn what a database was ("Why wouldn't you just have the data in a data block or something? Oh, its going to change over time...I get it...") Once the school year started, I became disinterested in school and did the job Co-op (working 1/2 days for credit and going to school 1/2 days). Soon after I just quit high school to program full-time. By the end of that year, I had written my first business package, a time billing system for a real estate appraiser.
What was your first language?
Commodore Basic was the first, but assembly for the Vic-20 and C64 were soon behind. Once I was being paid to do it, I cut my teeth on non-mainstream languages like FMS-80 (sorta like Pascal), dBase II, III, III+, 4 and on to Clipper eventually.
What was the first real program you wrote?
I don't remember the first program I wrote of any consequence. The first one I can remember was the time billing system for the Real Estate appraiser. It was all green screen magic. Sometimes I miss the simplicity of UI design for green screen terminals..
What languages have you used since you started programming?
From what I can remember: Commodore Basic, 6510 Machine Language, QBasic, TurboPascal, FMS-80, dbase II (et al.), FoxPro, Clipper, Visual Objects, Delphi, Paradox, Visual Basic, C, C++, JavaScript and even VBScript.
I use C#, VB.NET and even C++ once in a while. I have been digging into IronRuby, IronPython, F# and Boo lately.
What was your first professional programming gig?
My first job wasn't that professional as I was paid minimum wage to mostly learn so I won't count that. Soon after I got a job creating a dBase II system to store a filing system for Chevron's environmental compliance area. This job involved creating a database that stored the data on every file in their file room, all reports for that system and a backup system for the data.
If you knew then what you know now, would you have started programming?
Yes I would. Having started so young, I fought it somewhat but in my mid-twenties I finally figured out that this is what I love to do.
If there is one thing you learned along the way that you would tell new developers, what would it be?
Many people think of programming as a solitary job for loners. I am often asked if I find the solitude nice in the work. The reality is that this job is all about people, not lines of code. Learning how to communicate with your team members, your customers, your advocates is key to success. I would rather hire a good communicator than a good coder. You can teach code, you can't teach how to communicate your ideas.
In addition, I would encourage people to read code. Reading code is a lost art. Intellisense and debuggers has made most younger developers dependent on watching the code in action. I feel lucky that I didn't have a debugger for a long time. It taught me to read the code to understand it. If you read code, you're liable to write code that is easier to read. Find code that impresses you and emulate it (e.g. good strucutre, documentation, etc.).
What’s the most fun you’ve ever had … programming?
I know I am going to leave someone out when I say this but without a doubt it was working at DevelopMentor as a developer. Chris Sells assemblies an incredible team that was spread out around the world with a vision to build a product called Gen<X>. Before I went there, I was always "the guy". In most offices I was the hotshot developer. Going to work with Chris meant that I was never the smartest guy in the room. While this was hard on my ego, it certainly helped me understand how to listen to other ideas and stand up for my own. Even though it was not a commercial success, it was certainly critical to who I am today as a developer, writer and thinker.
So who's next?
I would nominate:
When I teach Silverlight 2, I stress an important lesson that I thought that we (as developers) had learned the importance of linkability of the web. Early usage of Flash was the first time I noticed this. A number of those sites would create nested functionality that never changed the URL. If the URL doesn't change, i can't bookmark it. Most Flash guys learned their lessons pretty quick, but now I am inundated with AJAX driven sites that try hard to not to do post-backs. That's cool, but if the URL doesn't change I can't link to it.
I've noticed this happening a lot with support sites. The first time I saw with an AJAX site was using the Intersoft's Developer Portal (http://www.intersoftpt.com). They treat the developer to a desktop-like experience, but if I can't send a link to my other developers for the latest patch, why bother making it on the web?
The latest is the game Spore's forums. Trying to help a friend figure out why its crashing, I found some good posts on workarounds but the site's address is always http://www.spore.com/forum. What's the point?
This post is a request...a pleading...begging even. Think about the usability of your sites. If it lives on the Internet, it should be linkable. Now if your site doesn't have state, this doesn't apply to you, but for the other 99.999% of the sites out there, don't get too caught up in the frenzy of AJAX or RIA to make your sites usable. The reality is that you can do this with Silverlight, Flash, AJAX or any web page. It might be more work, but the level of frustration for users is well worth your time.
(NOTE: Microsoft is working on a new version of their AJAX toolkit to enable URL changes during partial page updates. This will help some of you, but the rest of you will still need to do some of the hard work yourselves.)
I am surprised when I talk to developers these days and they don't know who Sara Ford is. She's responsible for CodePlex and many open source initiatives at Microsoft. In addition, her blog is an excellent source of information on Visual Studio tricks and features that most of us have never noticed. It is well worth a read. Just announced today, her blog is now available in Russian and Spanish so if English isn't your native tongue, you're in luck there too.
Wonder how I get someone to translate my blog into other languages ;)
I've spent a lot of time the last few weeks looking at some of the new buzz words in software development. Domain specific languages, dynamic languages, TDD, DDD, *DD, etc.. Most of these ideas have definite benefits to the work of software development but I think they miss the mark on what is really hard in software.
In most projects I've worked on the past twenty some-odd years, the hard part is not how to architect a project, not how to tune a database and not how to eke out every CPU cycle of a function call. In fact the hardest part has always been in understanding how a business does business. There are many names for this but I like to think of this as domain specific knowledge. It's the time in the meeting room with the business veterans (stakeholders of one sort or another) that understand how it really works. Whether that is how freight is shipped across country, how users register with forums or how those scanners at the grocery stores actually work; in all cases these stake holders already know how they do or want to do their job. It is our work as developers into transitioning that into actual software.
Eric Evans talks about this in his Domain Driven Design book, but I think some readers of his book seem trapped into thinking that the magic of the domain is the top-down design of a system. In my opinion they are missing the point. Turning domain knowledge into a system is hard work, no matter what design methodology you use.
It's a people problem. We engineers talk in terms of code, architecture and data. We have our private language that helps us communicate. If you don't think that's true, ask your spouse/partner what happens when they hear you talk about work with your friends. The thing is that in most industries this is true. When you talk to stake holders, they have their own language too. Our job is to pull that information from them and translate it into software designs. Often a small misunderstanding can be the cause for large changes in a system. Getting this knowledge transfer right is crucial. For the most part we do an admirable job of it, but I think it is critical to understand how essential this is. Constant communication with the eventual users of a system is a key to the long-term success of any project.
So, if you've stayed with me this far we're probably in agreement about the importance of domain knowledge. Here's where I get incensed. So much of development these days is being done by outside developers. The strategy of business to keep developers around has vanished. This is evidenced by off-shoring, outsourcing and contractor-based development. Companies are attempting to cut costs by using cheaper developers as well as development teams they can cut loose once a project is complete.
The problem with this strategy is that all the domain knowledge is leaving the enterprise. Companies spend a lot of money for a project and some percentage of that money is in teaching the development team about the problem domain and the way that the company does business. By having short-term development strategies all this knowledge isn't being recouped by the companies. I don't think they understand yet what a bad deal this is for them. But it's not just bad for companies, it is also bad for developers.
In some sense we developers are part of the problem. Quitting your $75K/yr job to be hired back at $75/hr seems like a good deal, but in fact it is not a good deal for either party. Your loyalty is to the paycheck and when you leave, the domain knowledge goes with you. This extra knowledge can help if you stay in the same industry but that's pretty rare. Usually you go to a new type of company and spend time 'ramping-up' on how they do their business. This seems bad for developers because most of the ones I know have passion for technology. They want to be part of a winning team. By being a well-paid mercenary it becomes easy to not care about what you are doing. At the end of the contract you just move on, forcing you to divest in a personal stake. I miss that part of this business. I have had more enjoyment about projects that didn't work than all the mercenary positions I've ever held (yes, I am looking at you Gen<X>).
The dirty little secret in my house is that I'd give up my business and go work for a company if I could believe in them and believe that I was part of something special. In some ways I think most developers are like that. But in this atmosphere of short sightedness, it just doesn't exist.
So do I have a call for action? No. I think that domain knowledge is an important idea that both developers and companies need to address, but I don't have a nice and tidy solution. This is a shift that I think has to happen in software development. Both sides of the table need to look long at the last five to ten years and determine if what we're doing now is better than before. Does it only feel better because each line of code is cheaper to produce (mostly a product of better platforms, not better coders). I hope this can change.
UPDATE: Here's an interesting link that has a different opinion of this subject:
http://thedailywtf.com/Articles/Up-or-Out-Solving-the-IT-Turnover-Crisis.aspx
Jeff Atwood is up to his old tricks. He's succinctly reminds me of why I read his blog so religiously (though like religion, I tend to be a cynic and not agree with everything he says). I read the McConnell books a billion years ago and have forgotten about this excellent analogy of painting the dog house.
Essentially it is saying that building a small project may require you to make a lot of shortcuts if time is of the essence. It is ok to make these shortcuts knowing that we will need to re-paint the dog house one day. Fido can live with rusty nails and flaky paint. On the other hand if you are painting a 747, you better get it right.
This is a basic issue with RAD development versus large project development. Development of any kind has to weigh the cost of any part of the project (including planning, isolation, containment, requirement gathering, bug testing, etc.) against the benefits. Unlike the analogy, the reality is that there is a wide ranging curve between the dog house and the 747. Most projects need some level of software engineering and process to get it right, but at the same time most projects require shortcuts to fit into schedule, skill set and feature set. That is the reality of software development...always has been.
Building reusable libraries, services and widgets takes time to get right and sometimes one-offing a feature is a better idea. But unlike painting, sometimes refactoring can help in big ways. Once you get the thick paint on the dog house, you usually will have to peel, primer and repaint to get it right. Software development is not always that way. Sometimes thoughtful shortcuts that can be refactored are the correct middle-ground. That's been my experience...especially the last few years as lines of code have become easier to write (e.g. fewer memory leaking searches, less ref counting fiascos, etc.).
Steve and Jeff are both right that you can easily turn a good project into a bad with inadvertent management decisions, but it is not quite that black and white.
What do you think?
After seeing Chris Sells' programmer type, I had to check mine...Chris and I are the same type...wierd...or good...I can't decide ;)
Your programmer personality type is:
DHSB
You're a Doer.
You are very quick at getting tasks done. You believe the outcome is the most important part of a task and the faster you can reach that outcome the better. After all, time is money.
You like coding at a High level.
The world is made up of objects and components, you should create your programs in the same way.
You work best in a Solo situation.
The best way to program is by yourself. There's no communication problems, you know every part of the code allowing you to write the best programs possible.
You are a liBeral programmer.
Programming is a complex task and you should use white space and comments as freely as possible to help simplify the task. We're not writing on paper anymore so we can take up as much room as we need.
