Anne Epstein - All Comments

re: NHibernate and Composite Keys

Anne Epstein — Tue, 05 Jan 2010 22:53:37 GMT

walkthewalk,

Unfortunately, I don't know of a way to get nhibernate to do that. You might consider asking on the NHibernate users list to see if they have some ideas: groups.google.com/.../nhusers

re: NHibernate and Composite Keys

walkthewalk — Tue, 05 Jan 2010 17:11:49 GMT

Thanks for a nice clear summary of using Composite Keys.

On question I have... the NHibernate documentation says:

"You can't use an IIdentifierGenerator to generate composite keys. Instead the application must assign its own identifiers. "

Does anyone know of a way to get NHibernate to generate part of the Composite Key? In my case, the Composite Key is three integers, two of which are set from the application. It would be usefule to have NHibernate to auto increment the third.

I'm stuck with a legacy schema and using a SQL identity column is not an option. Nor is introducing a new primary key.

re: Intro to series on quality VB.Net

Kevin LaBranche — Sun, 03 Jan 2010 15:06:09 GMT

Your theory at least sounds good. :-)

I never thought much about the VBA to VB connection and in that case I would agree that this connection didn't teach much on code quality. VB was designed for RAD and it did that well. VB's beginnings pioneered / fostered RAD development but now other languages have caught up but where those communities kept going with quality ideas, VB did not. Perhaps the idea of RAD hindered the ideas of code quality and now the VB community needs to catch up.

......And of course, I could be way wrong on that to. :-)

Not that the why matters much as you mentioned in your tweet to me. I am really curious personally to understand why since I have been a VB'r for a while and know the language isn't perfect but which one is?

None the less, to make myself a better developer I have been working in C# on the side and have enjoyed it. My initial adversion to semi-colons is gone. =)

Thanks,

Kevin

re: Intro to series on quality VB.Net

Anne Epstein — Sun, 03 Jan 2010 04:06:20 GMT

Kevin, thanks for your comment!

I can't say for certain, but here's a completely unsubstantiated theory: it may be more common (or may have been more common a few years ago, at least) for VB programmers (vs. C#) programmers to have become programmers via Excel/Access programming and the like, i.e. very concrete procedural-type tasks, whereas I'd guess at least historically, C# programmers are more likely to have roots in university than VB programmers and thus by default arrive into programing with a stronger background in abstract thinking (though some argue, a weaker background, in, say, thinking about things practically) Any particular programmer favoring either language might be nothing like the profiles I've outlined, but if on a larger scale the body of programmers in each language trend slightly like I have described, that might be enough to change the language-wide stylistic preferences and the like. Again, I may be completely wrong in this theory, there may be something else entirely behind the difference in culture.

re: Intro to series on quality VB.Net

Kevin LaBranche — Sat, 02 Jan 2010 18:24:43 GMT

I agree and I think you have given a well rounded answer in that VB can do it but it seems that many who are using VB do not. For a while now I have been diving into topics like DI, IOC, SOLID, etc & almost all examples/tutorials & books talking about it has used c#. My first exposure to VB was back in the 3.0 days and real started using it professionally in 6.0. Since then I naturally moved to VB.Net and only now have really started to branch out a little with C#. (Shame on me by the way for not writing in other languages).

I am not sure why VB has this issue. As you stated, it is possible to do. Perhaps it's a holdover from VB's beginnings? What do you think?

Thanks,

Kevin

Social comments and analytics for this post

uberVU - social comments — Sat, 02 Jan 2010 06:48:28 GMT

This post was mentioned on Twitter by devlicious: New Blog Post On Learning: As programmers, we work in a discipline that is a bit different from that of many of the... http://bit.ly/83snWj

re: On Learning

Rob Reynolds — Tue, 29 Dec 2009 22:49:43 GMT

@Thomas: I work for one of those companies. I imagine they are far and few between though. The developers that work here on average have been here for 5+ years (to give you an idea).

@Anne: This is wonderfully written and encapsulates much of how I feel about software development. It's so unlike anything else you can do and that's why I love it.

Congratulations on the new job! Is there a nickname for the retreat? Anything fun like Practice with Palermo or Progresssion with Palermo?

re: On Learning

Thomas Weller — Tue, 29 Dec 2009 07:51:04 GMT

I wholeheartedly agree with your arguments. They formed essentially one of the main reasons why I quit being employed altogether and became a self-employed contractor - I wanted some more freedom to decide on the things that are important to learn and the time that should be invested for it. Now I can take me that time and can then bring that to my customer's account as appropriate - and hey, it makes me as well as my customers much happier...

I think, there are two general problems - at least in my corner of the world:

* First, the people who decide upon the hire/fire issue, often are business people who have no deep insight into the problem domain. Most people think that programming is 'writing code' and overlook the fact that it is much more something like 'providing solutions based on technical knowledge'. I even saw a developer's competency and productivity being judged by the produced number of code lines!

* Second, many companies tend to look only at the short-term financial gain of a software project. So all too often, 'code-and-run' is the preferred programming style in such companies - of course it's not an official strategy, but it's intrinsically promoted by the companies' policy.

I have heard of companies, that understand the problems and know that sustainability in software development is a huge cost factor (mostly the biggest one, much bigger than immediate development), and that this means that they need a loyal team of well-trained, highly capable developers to be successful in the long run. But I've never seen one in real life yet...

re: NHibernate and Composite Keys

Anne Epstein — Mon, 23 Nov 2009 14:09:36 GMT

Thanks, bonskijr! Great catch. I'd set things up for serialization but forgot to actually mark it as such, or put in info about that... oops. done.

re: NHibernate and Composite Keys

bonskijr — Mon, 23 Nov 2009 08:50:34 GMT

Nice post on composite ID, one thing that was missed is that CompositeID class should also be Serializable(ie marked Serializable attribute)

re: NHibernate and Composite Keys

kibbled_bits — Sat, 21 Nov 2009 15:26:40 GMT

agreed, I'm "getting" to execute stored procedures now from NHibernate (someone else's DB) much to my dismay

re: NHibernate and Composite Keys

Anne Epstein — Sat, 21 Nov 2009 15:00:53 GMT

kibbled_bits,

Agreed, absolutely-adding in a surrogate key is a preferable idea if that's an option...unfortunately, sometimes, be it the fact that the composite key is *already* being used all over the place as a FK, or, well, politics, you're stuck with the composite. still...hmm...maybe a post discussing migration is warranted...

re: NHibernate and Composite Keys

kibbled_bits — Sat, 21 Nov 2009 06:46:17 GMT

Nice, my only thoughts are that I like adding a surrogate key to cross references tables for a couple of reasons. One is because I get the uniqueness & avoid a composite key. Secondly a lot of XREF tables eventually have a table hanging off of it so I only have to propagate the surrogate to the children.

re: You are your Institutional Knowledge

Sarita — Wed, 21 Oct 2009 19:47:59 GMT

Like many companies, mine has gone through layoffs; however I see the lay-off trend continue within the same organizations. For sure a benefit of the recession is to lose sub-par performers, but belts continue to tighten so the differentiating line between who stays and goes and why has gotten a lot blurrier. Sometimes it's financial, sometimes it's arbitrary and sometimes it's combining 2 positions into 1.

Institutional knowledge therefore becomes even more critical in the current environment, particularly when it comes to the daily operations. Day 1 through Day 30 - what do you do and where do you get the information if your "go-to" person is gone? Technology certainly plays a key role here. My firm has invested heavily in electronic repositories and required documentation so we aren't left in a lurch if the go-to person didn't leave a good audit trail. Technology helps BUT IT"S NOT ENOUGH! If you operate in a high touch environment, service delivery WILL suffer despite efficiencies gained through technology. If you're client facing, internal or external, It takes time to transfer knowledge from your predecessor and do it effectively. Care has to be put if one is to make a seamless transition but if there's a lack of investment in this effort, how is one setup for success? Not spending enough time to answer this question is what I'm seeing in today's market.

re: You are your Institutional Knowledge

Erica Janine — Thu, 08 Oct 2009 17:41:13 GMT

I do not agree with the comment above. Companies generally lay off their weakest employees, true, when it can be determined. In more technical environments, the ability to even determine who is technically stronger or weaker is really not there in favor of appearance of importance. The very fact so many silo situations exist in big companies today goes to illustrate it is impossible to determine who knows what they should because the projects/items being worked *are* so specialized. In healthy technical or software-oriented groups, cross-training and common development is the norm, not the exception.

In big companies whose primary industry is not technology (i.e. most corporations), silos exist because software is NOT the focus. In this scenario, it is likely that only the most invisible (not necessarily the weakest) or most disliked employees are let go.