|
diegosendra wrote: Indeed, coding requires working from monday to monday. If you really want to be
productive working for your own, you have to do this, no matter if you code
everything yourself from your room or have a small team that you have to manage
or do both things. It's 14/hours a day, 365 days
I very much agree with your original post, but this statement I must disagree with. You owe it to yourself, and your family, to work sensible hours and spend time with them. If you can't make enough money to live on (and prosper) working a 40 hour week, then it's time to give up having your own business and work for someone else.
Are you going to lie on your death bed wishing you'd worked more, or spent more time with your family?
Also, remember the 80/20 rule. 80% of your income probably comes from 20% of your customers, so cultivate those relationships that produce the goods.
Lastly, learn how to say "NO". It's certainly one of the hardest things I have learned how to do in my business life, and it still is difficult to say, but sometimes, it's simply not worth your time to go and do some of the work, particularly if there are other companies who specialise in that kind of thing - for me, it's PC break/fix stuff. There are a multitude of companies around here who do only that, and they come to you... mostly stocked by young, eager nerds. Why would I want to take on that kind of work (when I am a software developer)? Yet people will phone up because my business is in their local area and want me to do it. I say no.
|
|
|
|
|
In some point, two or three years ago, I discovered that coding as primary job is a dead end.
Then I switched to project management and scrum mastering.
Benefits:
1. Still working in "application development" and having contact with new technologies
2. Finally having time to code for fun (when and what I want!)
If you're sick of it - think about something else to do. It will not pass or get better. 
|
|
|
|
|
cmd.Parameters.Add("@SomeID", SqlDbType.Int)
cmd.Parameters("@SomeID").Value = Session("SomeID").ToString()
It appears this developer didn't have a strong conception of data types, knowledge of AddWithValue, or knowledge that the "@" is optional when specifying parameters. 
|
|
|
|
|
AspDotNetDev wrote: SqlDbType.Int
Soooo many practitioners think that's necessary. 
AspDotNetDev wrote: AddWithValue
I never use that; it's not defined by an Interface I use. I use IDbCommand.CreateParameter and IDataParameterCollection.Add.
AspDotNetDev wrote: is optional
That may be true with the database system you use; it may not be true with all the database systems I use.
|
|
|
|
|
I also prefer to see it, even if optional because it makes it more obvious that it is a required parameter.
If you get an email telling you that you can catch Swine Flu from tinned pork then just delete it. It's Spam.
|
|
|
|
|
PIEBALDconsult wrote: Soooo many practitioners think that's necessary
I find nothing wrong with specifying that. The thing I find funny is the specification that it's an int, and then on the next line passing in a string, which was actually an int to start with (rather than casting to an int).
PIEBALDconsult wrote: I never use that
The first thing I did was convert it to LINQ. Now the call looks a bit like context.SomeStoredProcedure(someInt). In my next project, that's basically still how I'll do it, only I'll be abstracting away the data source and using Ninject, so where it's actually used it'll look more like dataStore.DoSomething(someInt).
PIEBALDconsult wrote: That may be true with the database system you use; it may not be true with all the database systems I use
I can't seem to find any documentation regarding the "@" being optional, but much of my code has been written with this fact in mind. SqlClient.SqlCommand knows to automatically prefix "@" for parameter names. I did come across this (see "Working with Parameter Placeholders"), which indicates the parameter naming varies per client. I wonder, then, if removing the prefix and letting the query composer do the prefixing is the best way for the code to be cross-client compatible.
|
|
|
|
|
AspDotNetDev wrote: I can't seem to find any documentation regarding the "@" being optional, but
much of my code has been written with this fact in mind. SqlClient.SqlCommand
knows to automatically prefix "@" for parameter names. I did come across this (see
"Working with Parameter Placeholders"), which indicates the parameter naming
varies per client. I wonder, then, if removing the prefix and letting the query
composer do the prefixing is the best way for the code to be cross-client
compatible.
That's an interesting point.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
nils illegitimus carborundum
me, me, me
|
|
|
|
|
I don't think there's a real way to achieve portability on that, it strongly depends on the connector used. ODBC for example uses a positional syntax for parameters, ignores parameter names and uses the '?' char as a parameter placeholder. MS-Access, same thing. The MySQL provider IIRC can be configured both ways, but by default requires the '@' char (or maybe the reverse, it has been a few years since I last used it).
Luca
The Price of Freedom is Eternal Vigilance. -- Wing Commander IV
En Það Besta Sem Guð Hefur Skapað, Er Nýr Dagur.
(But the best thing God has created, is a New Day.)
-- Sigur Ròs - Viðrar vel til loftárása
|
|
|
|
|
AddWithValue is the best thing since sliced bread (except for bacon)... Makes everything a hell of a lot easier. 
Why can't I be applicable like John? - Me, April 2011
-----
Beidh ceol, caint agus craic againn - Seán Bán Breathnach
-----
Da mihi sis crustum Etruscum cum omnibus in eo!
-----
Just because a thing is new don’t mean that it’s better - Will Rogers, September 4, 1932
|
|
|
|
|
I quit using AddWithValue when I discovered it eliminated the query optimizer's ability to generate efficient queries. With Stored Procedures it's probably ok, but if the query is embedded in your code it's a performance killer.
|
|
|
|
|
Easier isn't always better.
|
|
|
|
|
AddWithValue can cause problems where conversions may not be as expected: better to use Add and be explicit about what you are doing. And what harm the @? Just because something is optional doesn't mean you shouldn't use it - verbosity is king - it promotes clarity.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
nils illegitimus carborundum
me, me, me
|
|
|
|
|
Notice anything else about why the code is strange?
|
|
|
|
|
Yes indeed, but I didn't think that was your point.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
nils illegitimus carborundum
me, me, me
|
|
|
|
|
My only point is to make fun of as many things as is possible in that code snippet. However, the only real thing wrong with it is converting an integer to a string and then using that string as the value of a parameter that was just explicitly specified to be an integer.
|
|
|
|
|
Indeed - but you missed the smiley! I took you seriously! I wouldn't do it in that way (even with correct typing), in any case - too clumsy and not reusable. 
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
nils illegitimus carborundum
me, me, me
|
|
|
|
|
AspDotNetDev wrote: "@" is optional when specifying parameters.
Actually I believe the "@" symbol only became optional in .Net Framework 2.0 and above, before that it was a requirement. Please don't take my word for that, but its coming from a rusty memory of my own personal experience.
|
|
|
|
|
Well, in the codebase I handle I'm enforcing a standard of explicitly stating the parameter type when using ADO.net. Granted, we're autogenerating the DAL using an internal tool, but it helps in a lot of situations. Example: when using a string field, if you specify the length, ADO.net will truncate the parameter to the expected maximum length. Otherwise it gets passed to the underlying db and the query will error out. For us, the former behaviour is preferred. YMMV
Luca
The Price of Freedom is Eternal Vigilance. -- Wing Commander IV
En Það Besta Sem Guð Hefur Skapað, Er Nýr Dagur.
(But the best thing God has created, is a New Day.)
-- Sigur Ròs - Viðrar vel til loftárása
|
|
|
|
|
I believe this line:
cmd.Parameters("@SomeID").Value = Session("SomeID").ToString()
Should be this:
cmd.Parameters("@SomeID").Value = Int32.Parse(Session("SomeID").ToString())
|
|
|
|
|
The best thing I ever saw while debugging code was comments in Polish. The variables were also given Polish names so discerning the possible usage was more difficult. I asked a Polish programmer to please translate the comments and he told me there was not an English translation possible. I've always thought that was funny. To this day, in the code, when someone wants to use the buffer class they construct a CBoffo, usually called Boffo. It always reminds me of Hans and Franz doing a SNL skit.
|
|
|
|
|
We outsourced the programming of an application to a pole (or whatever people from poland are called) contractor once. What did we get? The whole program written in polish, even the documentation was in polish.
|
|
|
|
|
That is pretty funny . Have you outsourced anything since then?
Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
SoMad wrote: Have you outsourced anything since then?
Nope. We are now writing the code in english on-site. And we still try to retranslate the polish code back to english.
|
|
|
|
|
|
SoMad wrote: Sorry, I feel bad for you guys.
No need to do so. We just hired another polish dev to write the code for updates of the app until we fully translated the source.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
