+1 for Google and some coding related insight
I don't use Google+, so I can't actually +1 them... but I noticed something upon logging in which was small but relevant to me. So I thought they deserved a congrats. I try to remember to sign out of my Google services after every use, because frankly, I find the notion of my browsing information being aggregated and used to serve myself and others like me a little creepy. But this also means that every time I want to use a Google service that requires a log-in I have to type in both my email and password. Today, the username was remembered and just the password was required. I'm a lazy bum, so this is pretty big to me and represent a usability change in the right direction.
Moving on. Been a GREAT past week and a half at work. The reason being that I told myself to shut up and remembered who I am and who I want to be. Which means, I had some code that was super tough to me because it was in an area I have only ever barely touched and on which there is very little documentation and examples that are easy to find out there.
I had been noticing lately that whenever something new and challenging popped up, I tended to push back more than I had in the past. And as a result I haven't been learning near as much as I had been in the past. And that is really not why I love programming. I profess to love both learning and programming. And, if my job only required to know and be able to execute upon a fixed set of skills, then I would have to admit that I am indeed replaceable. The ability to adapt and to learn new thing, even tough poorly documented things, is what, in my opinion, makes me an invaluable member of my team.
I haven't sorted out all of my problems yet. I have two related, but potentially different sets of problems to deal with. Since they are work related, I will stick to generalities.
The first item was from last week and it trickled into this week. Basically, we use Linq-To-NHibernate to populate grids in our application. And there was a scenario where we needed to aggregate and group by 2 columns. But, all I have is the column names. Which doesn't work in a pure Linq scenario. And, the DynamicLinq library didn't support this level of interaction either.
I had a solution in place which took the dynamic linq we were supplied and converted it into a Criteria search in NHibernate. And this was a cool piece of software I had written a while back, AND it has stood the test of time. But, it didn't support a new feature we had added to the core part of our software. And, frankly, I had always disliked that this particular part of the software deviated from the Linq approach we used elsewhere. Conformity is a valuable in any project, but in larger projects this is even truer.
So, I was challenged last week to make this aggregation logic work with this new functionality. And I knew this meant *somehow* going to back to Linq.
The secret was Expression Trees. Expression trees are really cool. And in a fashion VERY basic. But at the same time, they are ass-backwards to any type of object oriented programming. Documentation is sparse, and examples are only on the basic ones. But, eventually I did indeed make it work. I'm still FAR from a master of Expression Trees. But I learned enough to apply it to a related problem on the UI side of the project. I feel confident enough now in my knowledge of Expression Trees to at least call myself a novice, if not a little past that. And having that under my belt is really exciting.
The added benefit of this whole endeavour was that, not only was I able to conform to the using Linq-To-NHibernate to get the job, which in turn brings that entire bit of functionality perfectly in line with everything else we are doing as a company. But it also allowed me to make the solution more generic, perhaps allowing me to bring this logic into a library that can be shared with other developers and products within the company. And honestly, that is the sort of thing that REALLY drives me. If I write something for just one product, only the users of that product benefit from what I've written. If I write something that every developer in the company can use, than I have an impact that goes beyond what I'm able to deliver on my own. And that is truly exciting.
But, yeah. It is work related, so no code here.
Also, on the work related side of things. That aggregate query I build returns data to be used in a grid. In the past I was using a homegrown grid. It had no data virtualization however, and adding enough elements could cause the browser to lock up indefinitely. So, what I started on today was extending an existing control which had data virtualization. But, it is a grid. And grid cells need to be bound to properties of an item contained in a collection. Since the query is dynamic, there is obviously no object we can bind directly to.
Which leads into the new thing I'm working on, which is also fairly exciting. And that is building a dynamic anonymous object and then binding that objects properties to the cells of a grid.
Crazy stuff. The past two weeks are getting closer and closer to going as deep as one can go in object oriented programming language like C#. I've not yet gone as low as emitting my own CIL code. But who knows... maybe a need for that will pop up somewhere down the road.
Moving on. Been a GREAT past week and a half at work. The reason being that I told myself to shut up and remembered who I am and who I want to be. Which means, I had some code that was super tough to me because it was in an area I have only ever barely touched and on which there is very little documentation and examples that are easy to find out there.
I had been noticing lately that whenever something new and challenging popped up, I tended to push back more than I had in the past. And as a result I haven't been learning near as much as I had been in the past. And that is really not why I love programming. I profess to love both learning and programming. And, if my job only required to know and be able to execute upon a fixed set of skills, then I would have to admit that I am indeed replaceable. The ability to adapt and to learn new thing, even tough poorly documented things, is what, in my opinion, makes me an invaluable member of my team.
I haven't sorted out all of my problems yet. I have two related, but potentially different sets of problems to deal with. Since they are work related, I will stick to generalities.
The first item was from last week and it trickled into this week. Basically, we use Linq-To-NHibernate to populate grids in our application. And there was a scenario where we needed to aggregate and group by 2 columns. But, all I have is the column names. Which doesn't work in a pure Linq scenario. And, the DynamicLinq library didn't support this level of interaction either.
I had a solution in place which took the dynamic linq we were supplied and converted it into a Criteria search in NHibernate. And this was a cool piece of software I had written a while back, AND it has stood the test of time. But, it didn't support a new feature we had added to the core part of our software. And, frankly, I had always disliked that this particular part of the software deviated from the Linq approach we used elsewhere. Conformity is a valuable in any project, but in larger projects this is even truer.
So, I was challenged last week to make this aggregation logic work with this new functionality. And I knew this meant *somehow* going to back to Linq.
The secret was Expression Trees. Expression trees are really cool. And in a fashion VERY basic. But at the same time, they are ass-backwards to any type of object oriented programming. Documentation is sparse, and examples are only on the basic ones. But, eventually I did indeed make it work. I'm still FAR from a master of Expression Trees. But I learned enough to apply it to a related problem on the UI side of the project. I feel confident enough now in my knowledge of Expression Trees to at least call myself a novice, if not a little past that. And having that under my belt is really exciting.
The added benefit of this whole endeavour was that, not only was I able to conform to the using Linq-To-NHibernate to get the job, which in turn brings that entire bit of functionality perfectly in line with everything else we are doing as a company. But it also allowed me to make the solution more generic, perhaps allowing me to bring this logic into a library that can be shared with other developers and products within the company. And honestly, that is the sort of thing that REALLY drives me. If I write something for just one product, only the users of that product benefit from what I've written. If I write something that every developer in the company can use, than I have an impact that goes beyond what I'm able to deliver on my own. And that is truly exciting.
But, yeah. It is work related, so no code here.
Also, on the work related side of things. That aggregate query I build returns data to be used in a grid. In the past I was using a homegrown grid. It had no data virtualization however, and adding enough elements could cause the browser to lock up indefinitely. So, what I started on today was extending an existing control which had data virtualization. But, it is a grid. And grid cells need to be bound to properties of an item contained in a collection. Since the query is dynamic, there is obviously no object we can bind directly to.
Which leads into the new thing I'm working on, which is also fairly exciting. And that is building a dynamic anonymous object and then binding that objects properties to the cells of a grid.
Crazy stuff. The past two weeks are getting closer and closer to going as deep as one can go in object oriented programming language like C#. I've not yet gone as low as emitting my own CIL code. But who knows... maybe a need for that will pop up somewhere down the road.
Comments
Post a Comment