yeah I'll delve into that tomorrow I guess but my WAMP has php 5.4.3 installed and dealing with :: stuff is a little beyond my several drinks coding tonight.

what's the error?
as a side note, you should use more descriptive variable names...

nevermind I'm an idiot, the middle of the 2nd for statement should have been a < rather than <=. Yeah. Thanks.

My terrible variable names are mostly in protest of the way that PHP doesn't allow statements in the place of variables the way JS does. In the above example there's no difference (in my mind) between
and

but PHP doesn't like the 2nd one which annoys me but oh well.

The issue is that you don't want to get the unique values out of the array until after you're finished populating it, which means it has to be outside the for loop. When you move it inside the loop you are trying to call array_unique on a string, which is what mysql_result returns. I don't think that works in any language that I know of that uses for loops.

You're "using a statement in place of a variable" in that code (unless I misunderstand what that means) when you do array_values(array_unique($result2))

also, array_* functions in PHP are completely in goofy in general

Git is driving me bananas. Almost lost eight hours worth of work tonight due to merge conflicts. People on Macs - do you use Source Tree, command line, or something else? When you have to merge do you use some external tool, or just do it by hand? Do you have strategies to avoid conflicts? I'm going to suggest we break everything into really small files until we get this sorted out.

We have hundreds of total years of version control experience in my office. But no one knows much more than beginner level at git. We barely even have anyone working on this project yet. It's going to get completely insane when we have a bunch of developers. We're using bitbucket. Is github any different? Looking at commercial licenses for one or the other.

I know I must be doing something really wrong, because it should not be this difficult. Every time we have a conflict, it's a nightmare trying to figure it out. I have no idea what the pull-commit-resest-stage-push sequence should be. One time somehow I managed to wipe out everyone else's recent changes. And then this time almost wiped out my own. Luckily I was able to hit ctrl-Z in sublime text, and get back to the previously saved file. Definitely liking sublime so far.

You should only get a conflict if two people edited the same line in a file.

When I get a merge conflict, I look at it, resolve it (just using vim), and then use git add (staging the file) which marks the merge conflict resolved. At that point I can do git commit to finish the merge. From then on it is normal git workflow (can commit some more, or use git push or whatever). I'm on the command line (Linux).

If you really screw things up and want to start over, you can always do git reset HEAD --hard to set everything back to how it was on HEAD (the --hard option will throw away all changes in your working directory). (This is assuming you have not committed anything after getting the merge conflict).

Regardless of any conflicts, it should be nearly impossible to truly lose any work. If you look at your history (e.g. using git log) you should be able to see the state of both of the merge parents, so no matter what the work should be recoverable.

Anyway, I'm not sure how to help your specific case further without more details.

I don't know is a great answer when you don't know.
So use what you know? It's supposed to be a tool that helps. If it doesn't make sense to invest in learning it then don't use it.

The only git tool I use is gitx (which is awesome for doing commits right).

Breaking up files probably won't help since conflicts are on the line level.

If you use gitx you'll probably get a good look at what you're actually committing and maybe that will help avoid extraneous changes that are causing conflicts.

Oh and of course use the standard mantra of commit, push, and merge often.

Git can't make actual conflict resolution easier but it makes it really easy to do lots of tiny conflicts instead of monolithic ones.

For learning OO:
1) Object-Oriented Software Construction (uses Eiffel as the language but that doesn't matter don't get scarred away by that)
2) Object-Oriented Design Heuristics

If you follow it up with "Domain Driven Design" + think through some domains and how you'd model them etc. you should be pretty much set for any question

Yes. There was tons of idk, but he then would just ask if I could logic it out or tell him what I think it would be.

coolio. Listed in my "get it later" file. Unfortunately, I really don't have the money for all these books. It's not by chance that I use all free resources.

Thanks yeah don't drink and code.

First one should def. be available in any university library (if they have a CS department), second probably less likely, third probably likely.

Joe Q Public is allowed to borrow books from the uni libraries in Europe?

You can find most classic programming books online, unless you are morally opposed to that sort of thing

This isn't helpful for your question but it strikes me as a terrible decision by management to use git if nobody in the office is any good with it.

Study there ldo. Forces you to actually read/take notes and absorb.

I came across this article, which seems pretty solid, thought it might be of interest to some of you guys looking for developer work

http://www.daedtech.com/guerilla-gui...per-interviews

Matthew McCollough and Tim Bergland do a nice course that's on Safari Books (both beginner and advanced) for using git. I generally like it but have not used other (except a little bit of subversion)

Generally I try to stick with the basics:
-git clone
copies repository into working directory
-git add .
adds all file changes
learn how to use .gitignore files
-git commit -m "put your comment here"
stage changes for pushing
-git push origin master
can also be: -git push origin some_branch
-git pull origin master
pulls master branch into your local repository and merges
-git stash
stash local changes and accept master changes. useful
when something irrelevant has changed locally
-git branch
useful when working in teams on branches. This gets to the point where I like to manually branch just by changing the names of files by adding _edit or similar and manually deleting my "branches"

Also useful for getting keys setup on multiple machines:

$ ssh-keygen -t rsa -C "[email protected]"

Enter file in which to save the key (/home/ubuntu/.ssh/id_rsa):
Passphrase (empty for no passphrase):

$ cat ~/.ssh/id_rsa.pub

After logging into your GitHub account, go to your GitHub SSH Keys settings at https://github.com/settings/ssh/. Click on the Add SSH Key button, give it a name and paste the contents of the public key into the Key text field. Then, click the Add key button. Enter your GitHub password when prompted

Perhaps its because I live in LA, where there are something like 90,000 homeless people, but uni libraries aren't open to the public.

For some reason, libraries make me really tired. I almost pass out in less than 30 minutes of being in one.

Excuse my incredulity: I don't believe for one minute that someone asking pointed questions is all a dog and pony show.

Considering you know my employment history, I'm saddened that you'd share this one with me -- unless it's not advice for me -- , since the entire thesis of this article states that my employment history is the result of me being a terrible person, which I'm sure you don't agree with.

What? I don't even understand how anyone can read that article and think it says they're a terrible person.

No it wasn't for you specifically - I'd have PMed it if it was - it was for developers to consider when looking for jobs, and it's one of the better articles on it I've seen in a while.

yeah, dave, i think you're being paranoid. it never even occurred to me that he was somehow commenting on your posts

[/URL]

Thanks a lot, this is the kind of stuff I was looking for. So in what order do you generally push, pull, commit? Do you use a merge tool to resolve conflicts?

To a couple of the posters who questioned why were using git: it's a combination of smart people we trust telling us that it changed the way they work, and immediate benefits like being able to share a code base with our creative team - who are on a completely different system that would be a nightmare to get set up on subversion.