185 karma · joined February 24, 2012
You basically take the nodes off one at a time, wait for connections to finish, sync over code, then bring it back up. This does make some assumptions about assets -- that they are in a different location, such as a CDN or static server. If you are removing assets, you need to do this at the very end of this node-syncing process, so that any live "old nodes" aren't linking to deleted assets.
As for newly updated assets, you should be doing versioning for those anyway (even this 'symlink trick' fails when multiple application servers are involved and no shared code space).
I had a dream last night where someone had an animated tattoo, which got me thinking about how that might be done. I figured you could have layers of tattoo ink done in different light spectrums, and then with special glasses that change spectrums slowly you could see the animation.
Then began the hell of trying to do anything "unixy" on OSX. Custom libraries just for the mac (custom libev??), needing to install XCode Dev Tools to get gcc compiler(???). Sigh.
In the end I just ended up running a CentOS VM in virtualbox, and I do my development there. The ONLY benefit I currently gain from a Mac is creating iOS apps.
So for a table 'user' you would have: user_id, user_name, user_password, etc. Some tables would have ridiculous long column names.
So what is this good for? First off, joins. If you had a 'post' table and a foreign key back to user_id, the naming scheme was: post_userid. So a join would be: "select from post inner join user on user_id = post_userid". There is no need to alias either table. Also, if both tables have the same field, say both have a 'note' field, it is clear which note you are accessing and there are no ambiguous issues (since one table is post_note and the other is user_note).
When you went to fullscreen in flash, it printed a giant "you are now in fullscreen mode" in the middle of the screen, but somebody showed that simply by printing similar text all over your screen, it hid that warning very well.
[sorry] we will not charge for development that happens under the “App Explore” product (i.e., the free version). Usage of the Appcelerator platform (Titanium Mobile SDK, Titanium Studio, Analytics and Cloud Services) at this level is permitted for all applications, both commercial and free, with no financial obligation to Appcelerator. [sorry, we aren't transparent enough]
The studio (Dynamix) did not "go under", they were closed by Sierra/Vivendi for "restructuring", which was a shock considering the success of Tribes 2. In fact, the next game (Tribes: Vengeance) was green-lighted due to in large part the success of Tribes 2.
GarageGames was partly made up of some ex-Dynamix employees.
Basically it's just a UI for using a controller while lounging.
1) change current password to some stupid password
2) give password
3) reset password back to my normal password
4) move on with life
it's becoming pretty standard, especially among techies, to have a unique email per site, so you can easily tell if a site is selling your address (or is a victim of a hack, like dropbox was).
I emailed them about it -- too bad!
a lot of employers are going to also ask: what do you do to keep up with the changes in technology?
also, learn SQL. it's easy, and necessary. pick a database, install it, become somewhat familiar with it.
if your goal is to only route HTTP requests, then you're only solving the first step of an increasingly complicated field of computer science (namely, web applications).
Cookies aren't going to go away. if you want to improve the protocol to deal with cookies better, that makes sense, but acting like they are some kind of evil on the internet that should be forgotten isn't going to work. it's a bit self-defeating to argue that some protocols failed because of failure to provide new benefits and then argue against Cookies in HTTP!
Pretty surprised to see node.js behave so poorly. We had discussions recently at where I work as to what server solution we should use for a multiplayer platform, and as I had recently built a socket/connection handling server in C they asked what I thought about node.js, and my only concern was that if the underlying code uses select(), then it's going to be a poor choice...but I don't think anyone got around to testing it.
search for: C10K for more information
"right" is always changing
in back-to-front, a line forms as you are waiting for people to store their bag. one person can take up [block] 3 rows of seats while he is fiddling with putting his bag overhead.
in random seating, people all over the plane are storing bags at the same time, instead of just 1 or 2 people.
that is how you handle errors in C.