At one company, I was conducting the technical interview for a C#
application developer position. I usually walk the candidate
through some very simple requirements, and move from general design
questions into specific questions about different aspects of the
program. After the candidate had finished explaining how he would
move data to and from the database, I asked "What do you do if
something goes wrong while executing the query?" and the
candidate responds curtly with "I'd debug it." Trying to gauge if
the candidate has real exception and resource management knowledge, I
press him with "Let's say there's an unforeseen problem in your query
or stored procedure that causes a crash. How is the exception
handled?"
He looks at me and said, as if this were the most obvious answer, "That will never happen. My code doesn't have bugs."
Chris_F
@Chris_F
Best posts made by Chris_F
-
RE: Interviews
-
RE: Interviews
I had another interview that stuck out. Ah, the folly of failing
to read the job description before firing off your resume and coming in
for an interview. The advertisement clearly read that the company was seeking an "experienced C#
developer." We receive a resume from a VB.Net programmer with "a
PhD in reality" and decide to interview him.
So he comes into the interview, and after pleasantries we get to
talking about his experience. Forgetting that he was a VB.Net guy
for the moment, I ask him to highlight some of his C# projects.
The poor guy says, "I don't do C#."
I ask, "Why not?"
"I looked at what I was doing, thought about it, and drew a line in the
sand. It's just not something I wanted to do with my life."
"You do realize C# and VB.Net are nearly identical languages?"
"I just don't like C#."
That interview was over pretty quick. -
RE: Interviews
@elnerdo said:
Why would someone who already does Vb.net even
LEARN C#? They're basically the same language; there would be no
point in learning both.
I'm not hiring interns. If the minor differences between C# and
VB.Net present such a significant road block, I would rather not have
such a person on my team. Experienced programmers usually have no
trouble adjusting to syntax differences within their chosen programming
paradigm.
Latest posts made by Chris_F
-
RE: .Net Generics... Just a class definition
[quote user="thisguy"]<font size="2">So let's say you have the following:</font>
public class MyBase<T>
{
public T ExposedField;
}
public class MyChild : MyBase<MyChild>
{
public Guid Id;
}What will happen when you instantiate a <font color="#2b91af">MyChild</font>? It will have two public fields: an Id of type Guid and an ExposedField of type MyChild. There is nothing strange about this and it is working as intended. In fact, the above example will compile and work perfectly fine (if you ever needed a class with an id that was capable of containing something of its own type). This is a very poor use of generics; however, it does work, compile, and perform as intended.[/quote]
Why do you say this is a very poor use of generics? It looks perfectly fine to me.
-
RE: When granularity goes too far
[quote user="treefrog"]I think there comes a point when creating a wrapper function for every feasible usage of the indexOf command or replacing the Math.round and/or toFixed methods is just too much. It's a waste of time and it doesn't really add any value.
If I'm reading the code and I see 'num.toFixed(2)', I'm pretty certain I know what's going to happen. Is it really necessary to type roundNumber(num,2)? If another developer has to inherit the code (which is where I'm at), and there's an error with that function, I'm going to have to hunt it down and figure out what's going on. If the intent is to round to the specified digits - just do it.[/quote]
It does something different than num.toFixed, though. While the current function is not ideal, its problems do not arise from its granularity. There are actually a few idioms encapsulated there, such as the type conversions and fallback values. I would have made the method even more granular by encapsulating the type conversion with fallback to a default value idiom as a function as well.
[quote user="treefrog"]If I'm checking for an instance of a space or an apostrophe, why not just use the builtin indexOf method inherent in the string?[/quote]
if (foo.Contains("x")) is clearer than if (foo.indexOf("x") != -1). Though not by much, of course.
[quote user="treefrog"]Do I really need to pollute the namespace, add overhead, and allocate memory for a function that's doing what a built-in method already provides?[/quote]
The overhead and memory here is trivial. Namespace pollution is not a very convincing argument either, because JavaScript has some very flexible structuring mechanisms - you can even place your extension methods directly on the built-in classes you extend, which is great. Contains, isVowel and roundNumber are clearly doing more than the built-in methods already provide. -
RE: When granularity goes too far
Why do you think these went too far? These functions clearly communicate their intent in a non-abstract manner, although I would prefer a "Contains" function to replace the first two.
-
RE: Version controlling stored procedures
@Little Idea said:
I recently inherited an data warehouse project built with packages in Oracle 10g.
My background is mainly application development, primarily using C/C++ and some java.
It drives me nuts that the packages and procedures are not version controlled.
The best idea I came up with so far is to extract everything out and put it into svn.
Does anyone have any tips or insight on versioning pl/sql packages?
Version controlling stored procedures is absolutely vital and must be done. Not only this, but any database transformation should be scripted out and checked in. No modification should be performed in production unless it's in source control.
I've enforced version controlled database changes by associating every change script with the work item. When it comes time to promote a development work item to QA, only those associated scripts are promoted. Thus if it isn't in the version control system, the change never makes it to QA. And if it doesn't pass QA, it never makes it to production.
-
RE: Java supports multiple inheritance, sometimes
@ammoQ said:
@VGR said:
You would write code like this:
Foo foo = new Foo();
String name = foo.getBaz().getName();
Date date = foo.getBaze().getDate();
Same functionality, no need for inheritance. You can argue that
you absolutely must override both methods of Bar and methods of Baz, in
one class no less, but as a design reviewer I'd need a better argument
than "I really want to use inheritance to do this."
Your example is bad style, it violates the Law of Demeter.
I disagree. The Law of Demeter often contends with the basic principles of encapsulation. If there really is a HAS_A relationship between Foo and Baz, it is usually far more maintainable to treat Baz as a distinct entity. Especially when there are a lot of relationships between entities.
-
RE: Java supports multiple inheritance, sometimes
@VGR said:
It does achieve the same thing. The only reasons to subclass are
polymorphism and inheritance of functionality. You obviously have
access to the functionality. The purpose of polymorphism is, in
this case, to let a Foo instance be passed wherever a Baz instance is
needed; instead of the Foo instance actually being a Baz
instance, you have to call (gasp) one method to convert it to a Baz
instance instead. (The method might be better named "asBaz()".)
Err, that's not polymorphism and no it doesn't achieve the same thing. What if the Baz instance needed to take advantage of some internal Foo members as part of the semantics of this relationship? This is easily achievable with an overridden method. Keeping them in separate classes is more work, breaks implementation hiding, and compromises encapsulation.
-
RE: Java supports multiple inheritance, sometimes
@Xenoveritas said:
Java resolves method names to implementation code at runtime, so it would have to handle clashes at runtime. It can't just reject them at compile time, since they can also occur at runtime.
Java is a statically typed language. Ambiguities are already rejected at compile time.
@Xenoveritas said:Generally speaking there are very few instances when you really need
multiple inheritance, and it generally just creates problems.
Er, speak for yourself.
-
RE: Java supports multiple inheritance, sometimes
@Nandurius said:
When you have two superclasses, and both implement a method with the same signature, which one is the VM supposed to call?
Some solutions:
1) Define an order. For example, give precedence to those classes that appear first in the list of extended classes.
2) Force an override on the subclass.
3) Allow subclasses to rename base class members.
@Nandurius said:Is <font face="Courier New">((base1)sub).toString()</font> going to return a different result as <font face="Courier New">((base2)sub).toString()</font>?
No, never. They must both use the same vtable for that call. For non-virtual methods, you probably want distinct behavior depending on the referenced type. C# has a kind of support for this with the 'new' method keyword.
@Nandurius said:Can you see the madness that multiple inheritance creates?
Not really. I think MI is an extremely useful tool, and it's a shame that even non-conflicting base classes may not be aggregated into a single subclass in popular languages like Java and C#. But as I've stated above, there's still logical solutions for when conflicts occur.
@Nandurius said:Interfaces are DESIGNED to avoid the problems that multiple inheritance causes, while still retaining ALL of their usefulness.
Interfaces are extremely limited; they do not retain all of the usefulness of MI.
-
RE: Cast/Convert/WTF?
@bullseye said:
@Chris F said:
I disagree again. Of course there is a difference in use, but I disagree that the differences are as trivial as you make them out to be.@bullseye said:
This is no different than having to change a string name for a column.
I disagree, I think it's very different..
C'mon Chris... Even a basic user knows there is a difference in use. I was referring to the level of effort involved for changing the ordinal, which is the same level of effort for changing a column name. Column names can change just as easily as column order, coming from a query. You touted readability, which I agree with. Using Getxxx( GetOrdinal( string ) ) stretches that a bit. If you still disagree, then just chalk it up to personal preference, since this is a very trivial point.
Ordinals are more likely to change than column names. Take, for example, a standard mapping function that maps some row of data onto an instance of an object. If you use ordinal access, you must ensure that the same data appears in the same position no matter what query returns it. This is extremely difficult if not impossible.
I do not consider Getxxx(GetOrdinal(columnName)) to be an access by ordinal, as the information you are supplying is the column name.@bullseye said:
In the case of the SqlClient implementation, GetInt32 handles casting between SqlTypes, Int32 does not. As I have already pointed out, there are scenarios where this comes into play, in which an explicit cast to a CLR type is problematic.
All accesses handle conversions between the SqlType structures and native types. I'm not sure what you mean here. In what circumstances will GetInt32 yield different behavior?
-
RE: Cast/Convert/WTF?
@bullseye said:
I did use a magic number in the example, which I agree is poor in practice, so I'll clarify. As with any constant value, I use constants to represent the columns. Should the columns be reordered, it's as simple as renumbering the constant. This is no different than having to change a string name for a column.
I disagree, I think it's very different. If a query is restructured to return the same results with different ordinals, your code must change while one that uses string names does not. Similarly, the names in a resultset are all that changes then ordinal access code does not need to be modified.@bullseye said:
@Chris F said:
Your above statements are nothing more than fallacies of distraction that focus on external forces instead of the WTF code in question.
Focusing on the code in question, why would you believe it to be a WTF without taking external forces into consideration?
I think you misunderstand. I'm talking about this snippet of code in isolation - that includes its solution to a common problem, and its possible inputs and outputs. You're talking about external factors like organizational processes. The WTFs with this code have already been clearly documented.
@bullseye said:However, as I said from the start and in every post after that, I see the code as lazy, not insidious. I don't like it, I don't use it, but the level of risk it poses is minimal.
That's really extraordinarily difficult to say, as this code may be part of a critical section that you're unaware of. Without context it's impossible to say.
@bullseye said:I don't like explicit casts for that matter, which I've already covered.
From a type safety perspective, there is no difference between (int) reader["foo"] and reader.GetInt32(reader.GetOrdinal("foo")). At least per the SqlClient implementation, both will perform a cast. One is not safer than the other.