The Joys Of Programming

Thanks everyone for the advice - I'll get started there. I may even approach the client about not using javascript, but I think they might have their hearts set on us using specific tools.

IlleBellus wrote:

Thanks everyone for the advice - I'll get started there. I may even approach the client about not using javascript, but I think they might have their hearts set on us using specific tools.

Javascript for the frontend coding, there isn't really much other choice

For the web application framework I'm with Bonus; pick a popular MVC framework. I quite like Rails but there are some neat super-lightweight ones out there

Bonus_Eruptus wrote:
bandit0013 wrote:
IlleBellus wrote:

Ok, y'all. I have a problem. I have to learn asp.net and javascript in a week. I am in a senior project for my undergrad degree and I have a background in Java, some C/C#, and no web experience that would be worth mentioning. Any recommendations on how to approach this? Our client won't start expecting anything for a week or two, but I have to move on it fast. I thought about just going and getting a manual, but I am usually more of a hands on/audible learner. Any suggestions (including "just suck it up and get a reference book you moron") are welcome.

Pluralsight.com Stick with webforms over mvc if you have the option, it's easier to get started with.

WebForms is awful and outdated. Go with MVC, even if it's a bit more difficult to grasp, which I don't really think it is.

We're talking to a guy who is a complete beginner. Webforms is easy because it works similarly to thick client technology. You can certainly go with MVC but good luck finding good resources to help you if you get stuck. There is only a small part of the .NET community that has embraced it and v2 to v3 to v4 have had some major revisions (Razor, etc). It's just harder to get started with.

/It is nice though, but I just can't recommend starting with it.
//You can mix web forms with MVC sites as well. So it doesn't lock you in.
/// slashies

Also, view the source of web pages you like Nd see what they do.

I would not recommend W3Schools because they often demonstrate subpar practices or have outdated info. In addition to a critique of W3Schools, you can find a list of superior learning and reference resources at W3Fools.

Other tips:
* Although jQuery is super popular and easy to use, make sure you are allowed to use it. Some clients may have strong preferences for other JS frameworks.
* You can get a very good idea of what's popular with both professionals and beginners by checking out the most popular JavaScript frameworks on GitHub.
* Are there any special requirements from the client, like accessibility or mobile device support? Do you need to consider security on client-server communication (passwords, forms, etc.) or have user-provided content (a vector for XSS, CSRF, and other attacks)? There are tools, frameworks, and best-practices to help with those if needed.
* As you build your prototypes and learning examples, get to know the developer tools in popular browsers. Live manipulation of HTML and CSS, breakpoints on executing JavaScript, performance audits, and other goodies will help you be more effective in chasing down problems (or just tinkering).
* If for some reason there's a requirement that needs HTML5-specific functionality, I seem to recall that Dive into HTML5 is a thorough resource -- don't spend time on this if you don't need to, though.
* You're probably worrying about a lot of the back-end functionality (and rightly so). When you get to the point where you need a nicer front-end, you might be able to pick up some tips here or here or from other "design tips for programmers" guides. I hear that this series of posts is also rather good. You can also check out sites like PatternTap or Dribbble or UI-Patterns.
* JavaScript has some rough edges; try to find a best-practices resource once you get through the basics. (Will let you know if I turn one up, but am in a hurry at the moment.)
* One of the more confusing idioms in JavaScript is ; (function foo() { ... })(); which has 1) a leading semicolon to guard against the remote possibility of screwing up code during script concatenation [which you probably won't worry about] but more importantly 2) a self-executing function, which is used to manage variable scope.

Wish I could be more help on the C#/ASP.NET end, but it has been too many years since I touched that. I'll post again if I think of anything else that will be useful; feel free to email me if you have questions (availability not guaranteed, but worth a try) and don't hesitate to search/post to StackOverflow.

IlleBellus wrote:

Ok, y'all. I have a problem. I have to learn asp.net and javascript in a week. I am in a senior project for my undergrad degree and I have a background in Java, some C/C#, and no web experience that would be worth mentioning. Any recommendations on how to approach this? Our client won't start expecting anything for a week or two, but I have to move on it fast. I thought about just going and getting a manual, but I am usually more of a hands on/audible learner. Any suggestions (including "just suck it up and get a reference book you moron") are welcome.

What kind of site are you building? What does it do? The choice of underlying technologies needs to at least give a nod to that.

In response to everyone:

I don't know that I have a choice in using tools of my choice. I've already had some tools set up for us by the client. So, I'm kind of locked in to these two. The back-end stuff won't be too much of an issue, it's just a matter of learning how to use the specific tools. Thanks for the advice, I'll keep looking in to the different resources you have all suggested. Needless to say I have another bookmark folder for all the stuff you have suggested. Thanks so much.

momgamer wrote:
trueheart78 wrote:

Was cleaning up my GitHub repos and started longing to see some old code I'd written, and then realized I still had a CD with the Visual C++ code I wrote in 2004 for my college capstone project (RISK in Visual Basic 6.0). I did put it up on in a repo - figured why not? Found the VB6 code too :)

I'm sorry, this struck me as another sort of bittersweet watershed moment. My college projects were on a mainframe that no longer exists. Some of the papers were on 5 1/4" floppies that have long since gone the way of the dodo.

Get off my lawn! Or at least don't do this to people on a Monday. ;)

I did homework in grade school on a Commodore 64 because I broke my finger really badly and couldn't handwrite. I used a tape recorder to save the state of my paper. Yeah, get off my lawn.

So I have a fun project this weekend. I picked up a set of these.

IMAGE(http://www.blogcdn.com/www.engadget.com/media/2012/10/image-hue-pack.jpg)

It turns out you can issue cURL calls to the controller (it has a RESTless API) and control the light bulbs. So I'm creating a script to ping Team City (thinking of trying out Scala), look for the state of the builds and then change the light bulb accordingly. So far I can change the color of the light bulb. That's pretty easy. Next up is pinging Team City for the state of the build. If I get that up and running I can use that at work to visually alert the team when the build is broken with a nice little lamp.

The next project, I think, would be to ping Jira and do math on the burndown chart and change the colors on a lamp based on the state of the sprint and how quickly tasks are being moved through the project.

Cyranix wrote:

I would not recommend W3Schools because they often demonstrate subpar practices or have outdated info. In addition to a critique of W3Schools, you can find a list of superior learning and reference resources at W3Fools.

Thanks for that. I just recall w3schools being useful as a lookup list for things like all the available tags, not actually used it myself/read it in ages.

It's amazing how the little things amuse me sometimes. At work the other day I ran across this most magnificent example of localized redundancy:
if (anInteger >> 0) {...
Just a minor little typo that didn't even change the logic enough to cause a bug. Someone had already fixed it. Once my brain recovered from the shock of something so inane, I was chuckling to myself for the rest of the afternoon.

Looking at it now, it's possible that C++ has finally driven me crazy (or at least crazier).

I've been fixing the data access layer of a project for a company. It always amazes me how little thought developers give to databases in general and how their database calls are structured.

In order to be "extensible" these developers before me decided to use Datasets with a ton of data tables in them (uh oh #1). In order to be even more extensible than that they decided to store all the executed SQL in the database. They don't cache anything, ever and each table has a data table instance in the dataset. They also decided to "reuse" entry screens for confirmation screens as well.

So they have this confirmation screen I've been refactoring... it's "very slow". Upon investigation it was doing the following:

1. Loading the sql queries to populate 5 drop down lists with data.
2. Loading the sql queries to populate data from 10 different tables
3. Executing all the queries one at a time
4. Setting the values of all the drop downs, and then immediately disabling them (since confirmation and all, data can't be changed)

So basically we were looking at 30 round trips to the database. I was able to get it down to 2. Data loads almost instantaneously now.

bandit0013 wrote:

I've been fixing the data access layer of a project for a company. It always amazes me how little thought developers give to databases in general and how their database calls are structured.

That is because engineers that are good at writing code are not good at relational databases and vice versa. There might be a few exceptions but it takes years to master either, and a lifetime to master both. The mistake that is made is letting application developers be involved in the database design and access.

kazar wrote:
bandit0013 wrote:

I've been fixing the data access layer of a project for a company. It always amazes me how little thought developers give to databases in general and how their database calls are structured.

That is because engineers that are good at writing code are not good at relational databases and vice versa. There might be a few exceptions but it takes years to master either, and a lifetime to master both. The mistake that is made is letting application developers be involved in the database design and access.

This. The amount of crap some of us are required to try and store in our melon is just simply boggling. Then I look at the non-indexed tables my co-worker puts together and thank God for that 1 database class I was required to take in college over 9 years ago...

While I agree that most developers haven't had much opportunity to learn database theory, if a screen is performing that poorly it boggles my mind that they couldn't look at what is going on, trace it, or something and figure out gee, it's all these database calls that are taking the time.

Besides which, I think it's just laziness. You can learn enough to be adequate in any database in a week. It's not all that complicated.

bandit0013 wrote:

While I agree that most developers haven't had much opportunity to learn database theory, if a screen is performing that poorly it boggles my mind that they couldn't look at what is going on, trace it, or something and figure out gee, it's all these database calls that are taking the time.

Besides which, I think it's just laziness. You can learn enough to be adequate in any database in a week. It's not all that complicated.

Laziness or some other form of incompetence, yes. Although mastering all the ins and outs of databases (performance tuning and such) does take some real specialization, schema design and basic performance guidelines for databases should be readily understood by every developer. I actually felt slightly insulted by kazar's statement because it seems to perpetuate unacceptably low standards.

Yeah. That example isn't so much "they don't get databases" as "they don't get computers".

Five things every developer who works with a Relational Database should know:

1. FFS (I have to swear about this, cause it irritates the crap out of me), LEARN THE DATATYPES. It is inexcusable in your programming language of choice to not understand the basic data structures, it is inexcusable when working with a database. If you don't know why it is bad to represent money with a float, stay away from the database. Varchar(100) is not supposed to be the type of every string data.

2. Understand the relational model- Primary/Foreign keys. Why repeating data is bad. Why composite keys are generally bad (not always, but generally). Honestly, I don't think you should be allowed to use an ORM until you understand this concept.

3. Understand how your database handles data integrity (transaction processing, isolation levels)

4. Learn the basics of how indexes work. You don't have to be an expert tuner, but you should know what an index is, how the database uses it, and why over or under indexing is bad. Bonus points if you learn what a covering index is and when it is appropriate.

5. In a business environment, take a deep breath and realize that many businesses have deep reliance on their data. If you corrupt or make data inconsistent, bad decisions can be made, people can lose their jobs. Treat your data with respect. Also realize that in general, the data will outlive your application.

/ Basically, I think that you are responsible for understanding your tools.

Cyranix wrote:
bandit0013 wrote:

While I agree that most developers haven't had much opportunity to learn database theory, if a screen is performing that poorly it boggles my mind that they couldn't look at what is going on, trace it, or something and figure out gee, it's all these database calls that are taking the time.

Besides which, I think it's just laziness. You can learn enough to be adequate in any database in a week. It's not all that complicated.

Laziness or some other form of incompetence, yes. Although mastering all the ins and outs of databases (performance tuning and such) does take some real specialization, schema design and basic performance guidelines for databases should be readily understood by every developer. I actually felt slightly insulted by kazar's statement because it seems to perpetuate unacceptably low standards.

That is the furthest thing from the truth. I believe in the highest standards. I am saying that anyone who doesn't have 5+ years of only DB experience (on a specific DB, not all DBs) is only going to cause problems if they take it up on their own to design database schemas or write their own SQL queries. And I feel that way too many people are too smug to admit they don't know databases well enough to do it right. This is why there are fields of study dedicated to database administration and engineering.

As for what every developer "should readily understand" I don't entirely agree. If a developer doesn't know databases, why is this a problem? As long as the team has a good DB engineer, he doesn't need to worry about those details. If he does know the basics great, but this doesn't mean he should go prodding his way into the database messing things up with everything he touches.

Maybe I am sounding grumpy, but it is because I have been on way too many teams where I see inexperienced developers working with databases acting like they are pros and I get to see and work with the results. Usually data sprawl across hundreds of tables with no consistency and queries that look like novels. I myself only have a basic knowledge of how DBs work and should be used but I can tell when something is really screwed up. Leave it to the professionals.

Edit: This is a rant. Please don't take this as a targetted attack at anyone here.

That's because most companies:

1. Don't understand the value of a good database administrator / team
1a. Thus developers end up being the pseudo-dbas
2. Many developers feel like the database team "gets in the way" so they insist on being able to go in and muck about.

(in response to #2, I tell developers that if they are using interfaces to their data layer with a good mocking strategy they don't need access to the DB right away unfortunately I think fewer people understand interfaces, mocking and TDD than do databases)

If you're at a small company, a DBA (let alone a DBA team) is a pipe dream.

Would you mind at least providing some recommended articles, guides or books for the developers that are stuck performing their own database management and query optimization?

trueheart78 wrote:

If you're at a small company, a DBA (let alone a DBA team) is a pipe dream.

Would you mind at least providing some recommended articles, guides or books for the developers that are stuck performing their own database management and query optimization?

Use the Index, Luke! is pretty helpful.

trueheart78 wrote:

If you're at a small company, a DBA (let alone a DBA team) is a pipe dream.

Which I find quite amusing and short sighted. Take this trucking company which is now a client of mine. Never had a DBA, contract or on-staff. I get a call from them, referral from a friend one evening, the "IT Manager", who is a glorified help desk technician, is panicked, near tears, because their server lost a drive and they don't know how to restore.

Ok, no problem, you have the backups, give me remote access and I'll be happy to bring them up.

Well, they had set up transaction log backups mixed with fulls... but didn't keep all the transaction log backups since the last full (they only took a full every month, but the tran logs they only kept for a week). I thought they were going to die right there on the phone when I informed them they had lost a month of data, and there wasn't crap we could do about it if they couldn't recover the drives that failed.

Every day they were down the estimated cost was several thousand dollars. Losing the month's worth of data packed an estimated cost of 100k.

If your business has data that is CRITICAL to the operation of said business, you are damn fool if you don't at least get someone part-time to make sure your backup/recovery solution is good. A lot of senior level DBA people like myself even have clients on retention... 10 hours a month, monitor your servers backups, do some tuning from time to time, just make sure the wheels don't come off. It costs about 10-12k a year, well worth it if your business can't function without its database.

Or at least put that sucker in the cloud. I don't understand why any business would install and operate a full blown SQL Server on site with critical data without someone to support it. You're just asking for trouble. Especially since most developers have nil understanding of the recovery models.

trueheart78 wrote:

Would you mind at least providing some recommended articles, guides or books for the developers that are stuck performing their own database management and query optimization?

The Accidental DBA is good for troubleshooting. Otherwise there are many SQL Server books out there, just pick one up. SQL Server 2008 R2 Unleashed was pretty good.

bandit0013 wrote:

Five things every developer who works with a Relational Database should know:

1. FFS (I have to swear about this, cause it irritates the crap out of me), LEARN THE DATATYPES. It is inexcusable in your programming language of choice to not understand the basic data structures, it is inexcusable when working with a database. If you don't know why it is bad to represent money with a float, stay away from the database. Varchar(100) is not supposed to be the type of every string data.

2. Understand the relational model- Primary/Foreign keys. Why repeating data is bad. Why composite keys are generally bad (not always, but generally). Honestly, I don't think you should be allowed to use an ORM until you understand this concept.

3. Understand how your database handles data integrity (transaction processing, isolation levels)

4. Learn the basics of how indexes work. You don't have to be an expert tuner, but you should know what an index is, how the database uses it, and why over or under indexing is bad. Bonus points if you learn what a covering index is and when it is appropriate.

5. In a business environment, take a deep breath and realize that many businesses have deep reliance on their data. If you corrupt or make data inconsistent, bad decisions can be made, people can lose their jobs. Treat your data with respect. Also realize that in general, the data will outlive your application.

/ Basically, I think that you are responsible for understanding your tools.

#1 makes me laugh. I work in a system built by people of dubious intellect and they use floats for money types. Oh so amusing. Of course they also wouldn't know what a FK relation was if it bit them on the ass. The system is huge and there are 17 total FK constraints and they were all created by me when I added a new piece of functionality to the system. Ugh.

One thing I will note is not all DBA's are created equal. For instance where I work they tend to be script running monkeys. Of course to me there is a difference between a DBA and a DB Dev..

This is a good blog to read on SQL stuff as well: http://sqlinthewild.co.za/

Without wanting to make a massive rant against my current employer, getting publicly chided over using source control and maven for a system data validity check (just need to make sure files that are referenced in a database table exist on the file system) by both a project lead and our manager is a bit ridiculous. For some reason I was dumb enough to agree that it would probably take a "couple" hours to write and turned into something I spent the majority of yesterday writing. I say "dumb" because I originally told them it would take a "non-trivial" amount of time to write which they interpreted as "more than a week" and I meant it as "more than a few hours". This was a somewhat time-sensitive piece of functionality, but mostly because they wanted to verify an issue in our new testing environment wasn't occurring in the production environment we're migrating to in about 2-3 weeks.

Was it unreasonable to snap back and say that not using SVN and Maven was "not the right way to do it"? Maybe I picked the wrong time to finally try and do a small project with Maven from the ground up (as our company is trying to use it more and I haven't really had a chance to get my feet wet with it)?

bandit0013 wrote:
trueheart78 wrote:

If you're at a small company, a DBA (let alone a DBA team) is a pipe dream.

Which I find quite amusing and short sighted.

DBA, Ops, and QA are three things I think are way low on the priority list at most "small" gigs. Or maybe mine's just the exception (developers effectively fill all three roles). Although we're certainly to the point where having at least one Ops and/or QA person should be priority, and QA was brought up at least 2-3 years ago. *sigh*

bandit0013 wrote:

/ Basically, I think that you are responsible for understanding your tools.

This goes double for any sort of platform you're developing on. I think I'm the only person on our team who has spent any significant time trying to understand the schema for the CMS one of our clients uses, or even reading the development/administration documents for that system. Of course, my company doesn't really think we need to have any formal training on that system which is just asinine and has bit us in the rear on multiple occasions. There are certainly a lot of bad practices you can fall into with this system, and they have a fairly decent Java and JSP taglibrary which makes life a lot easier when you try to use it properly.

So you have a developer, chances are at a mid-level you're paying 50-75k depending on the region. A QA person costs half that. I don't understand why on earth you would want 3 developers spending 30% of their time doing QA from a cost perspective. Not to mention that doing QA on your own code is probably the worst way to attain quality anyways, since you are more likely to overlook things.

Because QA is overhead. When they don't have anything to test they are dead weight. Same with DBAs - when the DBs don't need Aing, they just sit around drinking coffee and getting paid, let the devs do that. Ops is the same - this software sh*t should just work; don't needs Ops if those lazy-ass devs did their jobs right.

Devs aren't overhead but they are lazy and overpaid and should all be outsourced to India where I can get 4-6 devs for the cost of one here in the states.

tboon, you just put a smile on my face. Thanks!

tboon speaks the scary truth...

Applying the same logic to other types engineering, why don't we just get the engineer to put up dry wall, pour cement, do the electrical, etc.... Those engineers are just lazy and overpaid.