Not sure if you're kidding (I think you are) but just in case I'm not exactly sure what would be vapid sophistry, and I promise you I wasn't trying confirm anything, I was just trying to help out, and give you a starting point for some additional learning, with an implicit offer of further help should you need it.

I think this is a good idea. Javascript can be a pain to learn, but ultimately it is a functional language (something you have experience with) and once you get past the learning curve and oddities, it is actually a pretty fun and powerful language imo. So yeah, it sucks that you have to constantly learn new technologies when you are only just starting out and not 100% comfortable with the first ones yet, but that's just sort of the reality of web dev, and it never really ends.


yeah i got you were doing something like this, but "this way" I meant having the buttons change from one list to another right when you clicked them, since that would never happen in an actual game (the values of the next list won't be determined until the action of the other players is complete). but it's not important, i assume you just wanted a simple way to see how it would be done in theory.

I have your code on my computer and I am examining it. I was hoping you'd pop up with something when I posted so now I am pleased.

Why do you use "self" instead of "this" and why do you depend on javascript's ';' auto-addition in the code?

yes, you are correct: I'm not trying to program in anything that could otherwise be done in clojure at this moment.

The functions Button and ButtonList are factory functions, that is, their purpose is to create and return a new object. Note that I am assigning an empty object to self. So self is not this. Self is just a blank slate object and I am going to add some methods to that object (which is the same as adding a property which happens to be a function) and then return it.

You can see this reflected in the way that I use the classes: I don't say "list = new ButtonList(...)" but instead I say "list = ButtonList(...)"

I didn't have to do it this way. I could have added my public API methods to the prototype, and created the lists using new, and used this. That would have been fine, but I find the way I did it to be easier to think about, and it makes it easier to create private methods via closures, which I did in that example (all the methods not listed in the public API are private).

The inconsistency was just me being lazy and typing fast. Depending on the auto-addition seems to be totally fine and in fact arguably preferable: http://mislav.uniqpath.com/2010/05/semicolons/

But it's not a point I want to carry a personal banner for. Feel free to call it a mistake an always use semicolons yourself.

EDIT: More on private members and methods in JS: http://javascript.crockford.com/private.html

Ah, I see. Quite a lot to learn on that language. I've watched a few of DC's videos, reading "Good Parts" and have a decent-sized cheatsheet, although it hasn't all sunk in yet. I'm just not that dedicated to the cause at this moment. One week of learning isn't going to get me very far.

I feel like I barely know Python, Scheme, Clojure, or C. I feel over-bloated with languages that I'm not "fluent" in, so I have to take a pause on learning more unless there is a seriously pressing need to do so.

Uh, that guy irritated me. I can't completely explain why but it was probably related to statements like:

I really sympathize, I do. But for making real world web stuff js is a must have and should prolly take priority over most of those. If that's not your main goal then yeah, just wait on it

yeah that quote is weird and pretty dumb. i think he makes a lot of good points though.

I decided I would never depend on the autoinsertion when I read this. Take special note of the one where the poster fixes a bug by commenting out nonexistent code.

http://stackoverflow.com/a/2003277/1...003277/1060752

But not depending on semicolons wouldn't help you in this case. He's using one. You'd be affected by this no matter your semicolon habits

A website simply serves as an easy conduit for presenting stuff to others. A half-assed GUI makes more sense to people than reams of github code.

If my goal was web building, I'd just master Drupal / JS / Responsive CSS, call it an education, and find a job to rot in.

I'm watching the AWS summit live stream right now (http://aws.amazon.com/live/) and they mentioned that they serve over a million requests/second for S3. Freaking crazy.

Edit: For sound it seems like you have to use Safari.

anyone have worked with a non communicative boss? i'm in a 4 people team and my boss doesn't talk about the projects or anything, just gives u tasks and it's very hard to work with him

how would u approach this, would u talk to him or would u leave the job?

Seems like it would depend on a whole lot of factors. Can you give more context?

he is the team leader and he is in charge of the projects and assigns us the tasks to do, usually the projects are updates to old systems here in the company and ocassionaly develop new systems

but the thing is that there are almost no comunication in the team so we dont know very well what is doing each other and how...obviously we dont know what he is doing and what projects are going to come

and we should do weekly meetings but he never do them and he says is always too busy

apart from that, he doesn't have soft skills so it isn't too easy to talk about some topic with him

there are other solutions to this problem, but i'd just look elsewhere. if you aren't terrible and don't live in BFE, the job market is too good right now to languish in a ****ty job.

This.

If for some reason you really really want to stay at this job - I guess I'd pick the thing that irritates me the most and work on that. Get a couple of concrete examples of the problem and suggest some ways to deal with it. It's a fine balance because ideally you'll want to come up with suggestions that:

1) Don't make more work for your boss
2) Don't make him think you're trying to take away his "power".

Its pretty challenging to do - so I refer you back to Tyler's suggestion.

Neither.

I'd talk to the customer and find out what they want. I'd talk to the customer and see if my work solved their problem.

I'd talk to the other team members and bounce thoughts around. I'd work with the other team members since 2 >>> 1.

This seems like a bad idea for two reasons:

1) It's probably going to make you guys look silly and disorganized to the customer. That's not good for anyone.

2) Its probably not going to sit well with your boss (it definitely wouldn't sit well with me) and doesn't really do anything about the problem.

yes very challenging , i've been thinking about this near a month

i haven't leave yet , cause the company isn't bad just this particular problem

but i don't think things are going to improve, so look elsewhere is a valid option

i have about 10 month here so is good time

and things that irritate me the most is just his lack of comunication, he dont even says when he is going to take holidays, the last time we knew the same day he was leaving lol

The customer is probably internal.

1) There is nothing silly and disorganized about finding out what the customer needs & expects. At least not compared to not knowing, guessing, and inevitably getting it wrong. That looks silly and disorganized. Finding out what problem you're actually trying to solve is good for lots of people. Consulting with your team members is really good for lots of people. Working blind and alone is not.

2) We've established the boss is not interested in communicating. So why would he say anything?

It definitely does something about the problem. The problem is the team members have no clue what they are supposed to be doing. The boss is not the problem. Expecting the boss to contribute is part of the problem.

Dead weight in technology projects is common. The best thing to do with non-contributors is to work as if they aren't there. They aren't nearly as damaging as negative contributors.

---

Just working to do the right thing technically (within the requirements and constraints) is a great strategy for a developer. You work out what is the right thing by building consensus in discussions with team members, customers, etc.

Results are what count, not excuses. The boss is likely to be lazy, not evil. I stand by my advice.

It doesn't matter if the customer is internal or not.

If you have the OP and the boss both talking to the customer than it absolutely makes you all look like idiots. The customer has to repeat stuff. Sometimes one person is going to contradict the other. If there's a problem the customer doesn't know who to bring it up with. And so on.

As for saying that the best thing to do with non-contributors is to work as if they aren't there - especially when that person is your boss - is just ridiculous.

i don't think he is either, i would say he is very technical, he is like those guys 100% technical skills - 0% people skills

and the customer is internal, but he communicates directly with the leader in meetings, so it's wierd if i go to talk to the customer directly

he manages all about the projects (or new projects that are comming), and he doesn't even share the gantt project, so that isolate the team members and we just receive tasks with a little clue what is going on

and i think he does this to take control and be in charge of the project, so he manages the big picture and we just do small annoying tasks

How is this worse than the customer tells the boss and the information disappears? Leaving the developers to work blind.

I think you're imaging this turning into a political issue when it doesn't have to leave the technical world. You can tell your boss you are talking to the customer because you don't understand the problem. Somebody has a problem they want solved. If you're trying to help them they will be grateful in my experience.
I'm quite jealous that you've never had to work with dead weight.

---

You can make excuses and blame the boss or you can solve the problem. I like solving problems. If I lacked experience or confidence then I could see not talking to the customer. There is no way around collaborating with team members though. You want to take advantage of the accumulated wisdom that is trapped in their heads.

ok. Software project management is a technical specialty in itself. Get him some books on the topic. Example: http://www.amazon.com/Software-Proje...ect+management

You should be able to have a technical discussion with him. Tell him you don't know wtf you are supposed to be doing. See what he says.

How long have you been at this place and what's your general experience and skill level? From what you're saying, I don't know if it's a terrible development sweatshop or a wax-on/wax-off.