Yeah dog also learn Smalltalk. Lots of jobs for that.

Is Cassandra like Mongo? I could use some web scale.

Amazing how quickly scale becomes an issue. My database at work, which I created and is way denormalized, lags on some queries, and I only run commands through PgAdmin. There's one table that has around 150k tuples and another that has around 500k tuples, then there is one that is 400x35. Some of the queries can take a few seconds to run. Definitely many lessons on the merits of running natural join vs join, using distinct values, and other stuff like that, but I just wanted something quick to create and easy to query. I had a ton of staging tables that I joined together and pushed into larger tables.

I could normalize it if I wanted to (had the time to), but since it's for my own purposes and no one else uses it, I don't really care and the time that it takes to just select a, b, c from MyTable isn't going to be offset by creating something more optimized since the longest any query takes is really about 5 seconds and I don't foresee this getting any worse. Just wanted to point out that scaling may become a slippery slope much quicker than you may realize, even in cases where you are only running command lines and you don't have to worry about servers, back-end, front-end, UI, etc etc etc. I give the guys who created Hold'em Manager and Poker Tracker a ton of credit for creating something that, though at times laggy, could query over million-hand databases in decent time.

I imagine this is a major issue in many programs and applications. For example, the official database at work must have around 5 million tuples on one of its tables. For example, if I queried over all sales within a 2 month period, I would have to wait for 5 minutes for the query and another 5 minutes for the export. This uses up all the computer's resources, and I have a very fast computer. Initially, I tried pulling up everything for an entire year. That was ugly.

You have no idea how right you are. Every small inefficiency explodes in your face as you scale to millions of hands. Some problems are simple, yet hidden, others are straightforward and confounding. The hardest part about it all is it's not obvious beforehand where the problems lie. You really just have to experiment and be at peace with how dreadfully long this whole process of discovery takes. Thank goodness for fpdb as I didn't have to start from zero. But it's been some road.

Broadly speaking, you have to think of it like a map. You have maps of the world, maps of a country, a state, or a city. If its something like google maps you can zoom in and out between all of them. At each level you're granted a certain amount of detail. You may be able to spot a neighborhood park on a city map, but you may not be able to even find the city on the world map unless it is large. It's the same thing with poker hands. At 10,000 feet, your never going to want to query all of your hands to build something like a lifetime graph. At that level you need to work with sessions, weeks or months. If and when you do need to see individual hands only grab a few at a time and make sure whatever your filtering on is properly indexed. Pre-caching this data is key, which makes how it's imported and stored just as relevant to performance as your select queries.

it's almost like large data is a hard problem! so hard, in fact, that it has becomes its own specialty in software engineering!

related to your map metaphor (and probably too nerdy for the wikipedia thread in oot): http://en.wikipedia.org/wiki/Coastline_paradox

this came up at work recently when someone posted this article using the coastline paradox to explain why estimating in software dev is so hard (i looked for a better link but couldn't find one; i'm talking about the michael wolfe response to this question; i haven't read the other answers):
http://www.quora.com/Engineering-Man...-factor-of-2-3

I think estimating software engineering tasks is hard because far too often any time based metrics were used to determine rewards or to get people in trouble and were therefore skewed so any analysis based on those numbers is flawed. Well, that and no one can agree on what a point is or how long it will take...

It's amazing how much more difficult management can make software estimation.

Complaints that the estimate is too long, no metrics comparing estimates to actual results, and (in the custom software world) pretending like a proposal estimate is the same as a scheduling estimate.

I've never actually coded Smalltalk but I find I like languages that derive from it. ObjC, Ruby.

Haskell fans sadly have fewer options if they're not the boss.

Hi, I'm applying for jr .net developer jobs in toronto area next starting next week.

I was thinking of creating a blog in .net, in which it would include the struggles, code, etc of me creating the blog. Is that or a portfolio even necessary for something to show potential employers..?

Thanks

Just sharing because I ran into it and it made me laugh.

http://thedoghousediaries.com/1860

A portfolio/extra stuff you can show an employee is always good. Go for it!

A blog seems like a good thing to write, you can get it to a finished state quite quickly and there's a ton of stuff you can add on to it.

Is this c#?

so what you guys are saying is that there is very very low amount of jobs available to haskell? makes me wonder why im learning it =/

Ya c#

I could get a half decent layout with database support in a couple hours... but then adding more features will take time I guess

Because I just answered a similar question on Programers.SE.

I would also recommend Eiffel, Meyer's book on object oriented code (Object-oriented Software Construction) is one of the best there is imo

Make sure to pick up some COBOL, with all the old programmers dying off there are going to be a ton of COBOL jobs...

Google wideband delphi, if you've not heard of it.

Its not great or anything, but its worth being aware of.

I wonder what path I'd recommend to someone starting out with programming these days who is free to chose whatever he wants...probably something like

1) Ruby/Python. Learn it, write code and especially understand why code is written in a certain way. Both are perfect to get started because they don't come with all the bloat of say JAVA while providing the same flexibility, encouraging good practices from the getgo and just being pretty fun overall.

Python has the upside of being used at Google and I think it's slightly faster than Ruby. Ruby has the upside of having the better OOP model (imo) and not having the Python 2/Python 3 "mess".
I'd say these days, go with Ruby I'm a Python guy but will relearn and do a little project with Ruby.

Bottom line...pick some projects that interest you and GET CODE DONE (also read good code for example for Ruby, read the library files)

2) Work on craftmaship, good practices etc
- Language best practices (Tao of Ruby or whatever it's called etc...basically understand why code is beautifull, what idioms are used, what code is horribe)
- General...get a copy of Code Complete and/or Pragmatic Programmer and read it
- Understand and use a revision control system such as Subversion (also understand why you want to use it)
- Write tests, research test first programming, write more tests...understand why having tests is good

3) It's a web world
- Pick up some web technology. Rails or Django are good starting points that kind of force you to learn everything you need on the fly while being fun and letting you get results quickly. Use the minimum prototyping environment i.e. SQLite, webserver that comes with the framework etc.
- Dive deeper into SQL, I suggest postgres because it has a pretty nice featureset and is open. No idea where MySQL is headed but while it's slightly faster and more widespread I think postgres is clearly the one to pick up these days...either way learn proper SQL that will work with any DB...oh and ignore the noSQL hype, I've been doing noSQL without even knowing about it for years (yay for ZOPE and ZODB)
- Dive deeper into other web related stuff, HTML, JavaScript, AJAX stuff

4) Branch out, get academic
- Tighter understanding of OOP (Books: Object-oriented Software Construction, Object Oriented Design Heuristics, Design Patterns)
- Pick up two extra languages
a) Job-booster (JAVA duh...I guess .net stuff if you're into that)
b) New concept language (Lisp/Scheme, Prolog, Haskell, ML, something aspect oriented)

5) Specialize
- Research what you're interested in (computer security, ERP systems, network protocols, APP development, microcontrolers) on a high level
- Learn appropriate language i.e. ObjC, C/ASM etc

Keep learning...probably learn about learning somewhere because that's basically what you do. Solve problems and learn
Oh yeah join an Open Source project, participate in Summer of Code or start your own company (or get a job I suppose)...just write code that's used

For the same reason you'd want to learn Lisp. You don't want to be the people described here.

I would say not really, but take my thoughts with a grain of salt since I'm not a professional developer, nor am I at any high level.

Blogs are simply too easy to do, even if you choose to hand-code it yourself. I created the requisite comment box and contact page, and include scripts all in PHP long before I knew what a For Loop was and I was lost on what a Function did (really, I was completely stumped on why or how to use arguments). My blog was even safe from injection scripts!

Either I am way smarter than the average bear or blogs are extremely easy. Now if I am saying they are very easy, and you see my description of myself above, imagine what a MS in CS is going to think?

You are also assuming that any interviewer actually wants to read your blog, and since you aren't applying for a writing job, I have a hard time believing a dev house really cares too much, and in fact, the only thing they will do is hit CTR+U and if they throw up, you probably don't have an interview.

While there is something to say about doing something extracurricular, I don't think a blog on coding a blog is anything above a yawn. Now if you blogged about writing a seriously difficult project you build from scratch, and this project took a few months, then you have something to blog about, otherwise, besides blogging about three things in .net, a few items on SQL, your blog will be all about the beauty of CSS and why you believe table layouts must die.

Programming skills are very transferable between languages... where I work, none of the new grads have any experience in the technologies that we use, but they all have prior 'programming' experience. Once you are good in one field of programming, its pretty quick to train you in another.

Basically what you want to do is signal that you're interested in learning interesting technology despite it not being "useful"l. You kind of signal that you enjoy learning.

It's a bonus that understanding stuff like Haskell makes you a better programmer in another language.

It never hurts to have actual results to show a potential employer. It doesn't matter if what you build is too easy for Dave, or if your HTML isn't perfectly formed and validated. What matters is that you start a project and finish it.

You also can't underestimate writing ability for developers. You need to be able to explain concepts clearly, verbally and in writing, to both technical and non-technical people. The best coder in the world is worse than useless if he can't explain to anybody what he's doing and why.

Anyway, given the job market in TO right now, I doubt you'll have difficulty finding work.

Having spent almost all of my coding career in the government sector, I was always able to say "my code is classified/proprietary/behind paywall", but it certainly didn't help me get any jobs. Two best startup interviews asked me to write something the day after the interview. Having the code sample ahead of time probably looks very good.

I'm going to be having an awkward conversation tomorrow. One of our other engineers basically reformatted half of a file that I own in his own coding style - we don't have super stringent standards about stuff like spacing/which line braces go on/etc., the general rule is just "stay consistent within a file." So I have to kind of WTF when he makes a functional change to one line in a function and yet reformats the whole thing in his preferred spacing/brace format and renames all the variables. Really?