We use longs for ids and strings for accessions or gene symbols. The id's
are usually used for joins and the accessions are used by users when doing
searches.
Mark
On Apr 16, 2013 11:10 PM, "Eric Jablow" wrote:
>
>
> On Tuesday, April 16, 2013 4:11:04 PM UTC-4, phidias51 wrote:
>>
>> Roland,
>>
On Tuesday, April 16, 2013 4:11:04 PM UTC-4, phidias51 wrote:
>
> Roland,
> We have a similar problem in the bioinformatics world, where a field like
> "id" could mean an ID from a specific database, an accession (an
> alphanumeric ID similar to a database ID). One way around this is to use
>
It would be nice to be able to specify the types of validations to be
performed in an ontology. It would make it easier for systems to share a
common, verifiable definition for a value. This would satisfy the DRY rule
across applications, APIs, companies, etc. But that's perhaps a little
beyond
I'd have to disagree. For constraints you're much better doing it in the
type system, where the compiler can check things for you.
e.g. Provide an argument of type ValidatedId instead of a String with a
bunch of annotations.
I'm also curious to see if the new 'Optional' type gets much adoption vs
On Tue, 16 Apr 2013 22:11:04 +0200, Mark Fortner
wrote:
Roland,
We have a similar problem in the bioinformatics world, where a field like
"id" could mean an ID from a specific database, an accession (an
alphanumeric ID similar to a database ID). One way around this is to use
semantic annotat
Roland,
We have a similar problem in the bioinformatics world, where a field like
"id" could mean an ID from a specific database, an accession (an
alphanumeric ID similar to a database ID). One way around this is to use
semantic annotations for fields. Here's an example.
http://aspenbio.wordpress.
While I generally agree that good code needs no comments, as an insider it is
sometimes difficult to judge wether some piece of code or a method name
satisfies the requirements of obviousness.
Particularily bad is the documentation of the domain model objects and methods.
Quite often in my exp
On Tue, 16 Apr 2013 11:20:34 +0200, Graham Allan
wrote:
You're right it's a different
scenario where say you have satellite developers working halfway across
the
globe.
In my experience this just happens across the same floor :-)
In your scenario, it still sounds like comments are a sme
I see your point. You've picked up on a bias in my experience towards
cohesive, self-organising teams, who practice pair programming. I was
trying to distinguish organisation from team: if I ship a library jar to be
used by the developer sat six feet away in the office, if she's not on my
team, the
On Tue, 16 Apr 2013 10:10:13 +0200, Graham Allan
wrote:
API vs Inline comments are a good line to divide across, but I suggest a
different distinction: whether the audience is in your team or not.
The difference between withing and outside of the team can be useless in
some contexts. It's
API vs Inline comments are a good line to divide across, but I suggest a
different distinction: whether the audience is in your team or not. If I am
writing code for someone in my team I expect them to have: the source
checked out and built; tests running; whatever environment they need set up
to b
The distinction between API documentation and inline comments is an
important one - the two have almost nothing to do with each other. I'll
assume that we're all on the same page about what constitutes good API
documentation: I want to know what the arguments are and in what ways
they're restricted
At face value, I do not see why programming should be any more unique than
any other process description out there. I like to bring actual cookbooks
and furniture assembly examples into play. Cookbooks are typically more
prose heavy then furniture descriptions. Even there, though, it is not
unco
It seems that a big thing that should always be discussed as part of this
topic is what the nature of the comments is. Javadoc was brought up and I
dare say that kind of information is absolutely necessary and is not on par
with inline comments that one only sees when looking at the source code
On Sunday, April 14, 2013 2:44:58 PM UTC-4, Reinier Zwitserloot wrote:
>
>
> Of course, let's be reasonable here: While in theory any and all comments
> are code smells, they are pretty much always the lesser evil. Anything
> beyond the most academic of projects is going to have some chunk of c
15 matches
Mail list logo
