We Keep Coding

Should I use fixed or dynamic time step in a networking game?

I am currently developing a online networking game using Box2D JS and Vert.x as the server->client framework.
I have searched for pros and cons of each and I really believe that a dynamic time step is much better since it does not assume that each client has the same processing power, however, there are some (many) people that think fixed time step is much better.
Please enlighten me.

You can basically throw determinism out the window if your timesteps are not synchronized. Even when they are, determinism is difficult.
Spending less computation on simulation will have real costs that may not initially be apparent. For each different setting (and in the case of dynamic timesteps/iterations, for each different individual execution) the resulting behavior on the same input can be different. You can have a user run on really slow hardware that can potentially completely cheat through your levels.
Determinism is perhaps marginally less important outside of a multiplayer engine context, however simply not having a deterministic system will make it significantly more difficult to reason about pretty much anything (gameplay mechanics, game difficulty, exploits) which can impact nearly every kind of game I can think of. Imagine a puzzle game that wasn't deterministic.

I really believe fixing the timestep is the best way to go. I can't remember clearly enough but in one of our games we were having troubles with dynamic timesteps during collisions. Ofcourse most people would say our collision detection code was either not well written or we could use some advanced techniques like ray casting, but we ended up landing on fixed timestep with a for loop that would do the physics update whenever the delay seemed longer due to slow processing power of device or some other reason (CPU busy?), etc. The process was simple enough and we were all happy with the results :)
I think the creator of Box2D himself is in favour of fixed timestep, I read it somewhere although can't find the resource atm.

Can we assume that you are trying to get the same results for the simulation on all clients? If so I think you need to explain your reasoning why having them all doing different calculations would be a good idea!
Or perhaps you meant that all clients will do the same calculations, but the timestep will vary during as the simulation progresses, but that is quite the headache to implement and debug. For each client to come up with the same (or at least similar) result, they will need to be using the same length timestep for each step, so you will need to send this across the network too, eg. physics step 32241 is 16ms, step 32242 is 18ms. Apart from requiring extra network traffic, each client does not know what length timestep to use until it receives this information. And where does it receive it from? Presumably the slowest client will dictate how fast everybody should be going? I can't see it working any other way. So client also have to continuously let the server know how much processing they can handle, and the faster clients will be dragged down to that level of performance.
But as Steven says, there will also be other problems even after these technical difficulties have been taken care of. Most notably the effect of gravity changes with different timestep lengths, so for example in a platformer, the height your players can jump would be continuously changing. If there are platforms that are normally just reachable, they might suddenly become unreachable when a slower client joins.
If you really did mean that each client will use just whatever timestep length it feels like, that would work but the server would need to send out an official snapshot of the world state at very very frequent intervals to get all clients snyced. Technically this would be much easier to implement, and each client would run as smooth as it could, but with more jerkiness as the world state is corrected to the official one, for clients that run either faster or slower than the server does. Hm... maybe this is the best way after all. You might be interested in this article explaining how Quake3 does something like this: http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking

How to become productive in Coffeescript?

I want to improve my Coffeescript coding style. When I program in Scala, I can write a module in an hour or two, run it and have only a few minor bugs that I can quickly identify and fix.
In Coffeescript, I spend about the same time up front but I end up having a staggering amount of small bugs that would have been caught by a static type checker and I end up having to compile, reload the browser, step through some code, add some break points, etc. It's an infuriating experience and takes significantly longer.
It's much harder to abstract and encapsulate functionality due to the lack of interfaces and many other OO-features.
Are there design patterns that replace the encapsulation/abstraction generally provided by OO? Or is there a primer/guide on how to think in a more Coffeescript-y way (or how to solve problems using a prototypical approach)?
What have you done to become more productive in Coffeescript (or Javascript - perhaps even any dynamically typed languages)?

If you're coming from a statically-typed, class-centric language like Java or Scala, learning JavaScript/CoffeeScript is going to be a challenge. The compiler doesn't help you nearly as much, which means that it takes you minutes to discover small mistakes instead of seconds.
If that's your major bottleneck, then I'd suggest embracing a more test-driven coding methodology. Use a library like QUnit to write small tests for each piece of functionality you develop. Used properly, this style gives you the same benefits as a static compiler without compromising the flexibility of a dynamic language.

Don't go straight to Coffee Script. Learn the core concepts from prototype and Javascript OO. IMMO You can learn both at the same time, but you will benefit much more if you get Vanilla Javascript first. Based on my personal experience, Coffee Script syntactic sugar for classes can be a trap if you don't understand prototypical inheritances (it's easy to get stuck on a bug).
Coffee Script debugging is still not a completely solved matter in terms of tools, the only way I know it can be done is to write tests (a pain when you're just starting) or look at the generated code (at least for the more obscure bugs).

It was odd for me too; in my case coming from a C/C++ background.
What clicked for me is that you can reduce your iteration time significantly with a few tweaks of your work environment. The idea is to reduce it enough that you can write code in small chunks and test your code very very frequently.
On the lack of compile time checks: You'll get used to it. Like significant white space, the lack of compile time type checking just melts away after a few weeks. It's hard to say how exactly, but at least I can tell you that it did happen for me.
On the lack of interfaces: that's a tricky one. It would be nice to get a little more help in larger systems to remind you to implement entire interfaces. If you're finding that you really are losing a lot of time to that, you could write your own run time checks, and insert them where appropriate. E.g. if you register your objects with a central manager, that would be a good time to ensure that the objects qualify for the role they're being submitted to.
In general, it's a good to bear in mind that you have decent reflection abilities to hand.
On the lack of encapsulation: Given that coffeescript implements a very nice class wrapper to the prototype scheme, I'm assuming you mean the lack of private variables? There are actually a number of ways you can hide details from clients, if you feel the need to, and I do; usually to stop myself from shooting my foot in the future. The key is usually to squirrel things away in closures.
Also, have a look at Object.__defineGetter__ / Object.defineProperty? Getters and setter can help a lot in these situations.
On reducing iteration time:
I was using the built in file watcher in coffee to compile the scripts on change. Coupled with TextMate's ability to save all open files on losing focus, this meant that testing was a matter of switching from textmate to chrome/firefox and hitting refresh. Quite fast.
On a node.js project though, I've setup my views to just compile and serve on the fly so even the file watcher is superfluous. They're cached in release, but in the debug mode they're always reloaded from disk, recompiled, and on encountering errors I just serve them up instead. So now every few minutes I switch to the browser, hit refresh and either see my test running, or the compiler errors.

Is JavaScript that bad for implementing heavy computation tasks?

How bad is it, to use JavaScript (CoffeeScript) for implementing a heavy computational task? I am concerned with an optimization problem, where an optimal solution cannot be computed that fast.
JavaScript was chosen in the first place, because visualization is required and instead of adding the overhead for communication between different processes the decision was to just implement everything in JavaScript.
I don't see a problem with that, especially when looking at the benchmarks game. But I often receive the question: Why on earth JavaScript?
I would argue in the following way: It is an optimization problem, NP-hard. It does not matter how much faster another language would be, since this only adds a constant factor to the running time - is that true?

Brendan Eich (Mozilla's CTO and creator of JavaScript) seems to think so.
http://brendaneich.com/2011/09/capitoljs-rivertrail/
I took time away from the Mozilla all-hands last week to help out on-stage at the Intel Developer Forum with the introduction of RiverTrail, Intel’s technology demonstrator for Parallel JS — JavaScript utilizing multicore (CPU) and ultimately graphics (GPU) parallel processing power, without shared memory threads (which suck).
See especially his demo of JS creating a scene graph:
Here is my screencast of the demo. Alas, since RiverTrail currently targets the CPU and its short vector unit (SSE4), and my screencast software uses the same parallel hardware, the frame rate is not what it should be. But not to worry, we’re working on GPU targeting too.
At CapitolJS and without ScreenFlow running, I saw frame rates above 35 for the Parallel demo, compared to 3 or 2 for Sequential.

If JavaScript is working for you and meeting your requirements, what do you care what other people think?
One way to answer the question would be to benchmark it against an implementation in a "good" language (your terms, not mine) and see how much of a difference it makes.
I don't buy the visualization argument. If your "good" language implementation was communicating with a front end you might be able to have faster performance and visualization. You might be overstating the cost of communication to make yourself feel better.
I also don't like your last argument. JavaScript is single threaded; another language might offer parallelism that JavaScript can't. Algorithm can make a huge difference; perhaps you've settled on one that is far from optimal.
I can tell you that no one in their right mind would consider using JavaScript for computationally intensive tasks like scientific computing. SO did have a reference to a JavaScript linear algebra library, but I doubt that it could be used for analysis of non-linear systems will millions of degrees of freedom. I don't know what kind of optimization problem you're dealing with.
With that said, I'd wonder if it's possible to treat this question fairly in a forum like this. It could lead to a lot of back and forth and argument.
Are you seeking a justification for your views or do you want alternatives? It's hard to tell.

Well it's not exactly constant time it's usually measured X times slower than Java. But, as you can see from your results for the benchmark shootout it really depends on the algorithm as to how much slower it is. This is V8 javascript so it's going to depend on the browser you are running it in as how much slower. V8 is the top performer here, but it can dramatically run slower on other VMs: ~2x-10x.
If your problem can be subdivided into parallel processors then the new Workers API can dramatically improve performance of Javascript. So it's not single threaded access anymore, and it can be really fast.
Visualization can be done from the server or from the client. If you think lots of people are going to executing your program at once you might not want to run it on the server. If one of these eats up that much processors think what 1000 of them would do to your server. With Javascript you do get a cheap parallel processor by federating all browsers. But, as far as visualization goes it could be done on the server and sent to the client as it works. It's just what you think is easier.

The only way to answer this question is to measure and evaluate those measurements as every problem and application has different needs. There is no absolute answer that covers all situations.
If you implement your app/algorithm in javascript, profile that javascript to find out where the performance bottlenecks are and optimize them as much as possible and it's still too slow for your application, then you need a different approach.
If, on the other hand, you already know that this is a massively time draining problem and even in the fastest language possible, it will still be a meaningful bottleneck to the performance of your application, then you already know that javascript is not the best choice as it will seldom (if ever) be the fastest executing option. In that case, you need to figure out if the communication between some sort of native code implementation and the browser is feasible and will perform well enough and go from there.
As for NP-hard vs. a constant factor, I think you're fooling yourself. NP-hard means you need to first make the algorithm as smart as possible so you've reduced the computation to the smallest/fastest possible problem. But, even then, the constant factor can still be massively meaningful to your application. A constant factor could easily be 2x or even 10x which would still be very meaningful even though constant. Imagine the NP-hard part was 20 seconds in native code and the constant factor for javascript was 10x slower. Now you're looking at 20 sec vs. 200 sec. That's probably the difference between something that might work for a user and something that might not.

Javascript Optimization, where to begin?

I've started work recently at a new company and they have an existing application with 1000s of lines of Javascript code. The baseline contains dozens of JS files with easily over 10,000 custom lines of code, they also use multiple 3rd party libraries such as Jquery, Livequery, JQTransform and others. One of the major complaints they have been receiving from users is the slowness of the client side operation of the site. I've been tasked with optimizing and improving the performance of the JS. My first step will be obviously to move forward to the newest Jquery library, and incorporate JSMin into the build process. Other than that I'm wondering if anyone has some tips on where to begin with optimization on such a huge code base?

You could try installing DynaTrace Ajax Edition (free download here) and see what that tells you. It supports only IE8 I think, but that's probably as good a place to start as any. It's got a much more thorough and understandable profiler interface than do either Firebug or Chrome, in my opinion.
One thing that jumps out at me is "Livequery", which if not used very carefully can cause gigantic performance problems.
Remember this: in a code base that big, developed over time and possibly not with the most "modern" Javascript techniques available, your real problems are going to be bad algorithms in your own code. Newer libraries and minification/optimization methods are good ideas, but the first thing you need to do is find the pages that seem sluggish and then start profiling. In my experience, in a big old codebase like that, you'll find something terrible really quickly. Install a desktop gadget that tracks CPU utilization. That's a great way to see when page code is causing the browser to slow down directly, and not just network lag. Any big spike in browser CPU usage for any significant amount of time should be a big red flag.

Profile that code. Don't optimize something if you just "feel" it could be optimized. Remember the 80% 20% rule. 80% of time is spent in 20% of code.
Use Google's Closure tools. They can optimize and reduce your JS code, which will at least cause it to load faster on your client's computers.

The way to go is to find bottlenecks. If you find the actual situtation where the app is slow, you can use Firebug to profile your code and tell how much time spent on every function and how many times they have been called. From this information it's pretty easy to determine what areas need some improvement.
Generally the bottlenecks of a webapplication are:
Working with the DOM extensively (repaints, reflows)
Heavy network communication (AJAX)

You have a long road ahead of you mate, and I dont envy you.
Here are some Performance Optimization Techniques for Javascript that I wrote down after working in a similar role as yours recently.
They are broken down into 5 broad categories in order of the performance difference they make.
However given what you said about the codebase, I think the second section on Managing and Actively reducing your Dependencies is the most relevant, particularly:
Modifying code to reduce library dependencies, and
Using a post-load dependency manager for your libraries and modules
However all 25 techniques listed there are useful for improving performance.
I hope that you find them useful.

Is using an obfuscator enough to secure my JavaScript code?

I'm working on building a development tool that is written in JavaScript.
This will not be an open source project and will be sold (hopefully) as a commercial product.
I'm looking for the best way to protect my investment. Is using an obfuscator (code mangler) enough to reasonably secure the code?
Are there other alternatives that I am not aware of?
(I'm not sure if obfuscator is the right word, it's one of the apps that takes your code and makes it very unreadable.)

I'm going to tell you a secret. Once you understand it, you'll feel a lot better about the fact that Javascript obfuscation is only really useful for saving bandwidth when sending scripts over the wire.
Your source-code is not worth stealing.
I know this comes as a shock to the ego, but I can say this confidently without ever having seen a line of code you've written because outside the very few realms of development where serious magic happens, it's true of all source-code.
Say, tomorrow, someone dumped a pile of DVDs on your doorstep containing the source code for Windows Vista. What would you be able to do with it? Sure, you could compile it and give away copies, but that's just one step more effort than copying the retail version. You could painstakingly find and remove the license-checking code, but that's something some bright kid has already done to the binaries. Replace the logo and graphics, pretend you wrote it yourself and market it as "Vicrosoft Mista"? You'll get caught.
You could spend an enormous amount of time reading the code, trying to understand it and truly "stealing the intellectual property" that Microsoft invested in developing the product. But you'd be disappointed. You'd find the code was a long series of mundane decisions, made one after the other. Some would be smarter than you could think of. Some would leave you shaking your head wondering what kind of monkeys they're hiring over there. Most would just make you shrug and say "yeah, that's how you do that."
In the process you'll learn a lot about writing operating systems, but that's not going to hurt Microsoft.
Replace "Vista" with "Leopard" and the above paragraphs don't change one bit. It's not Microsoft, it's software. Half the people on this site could probably develop a Stack Overflow clone, with or without looking at the source of this site. They just haven't. The source-code of Firefox and WebKit are out there for anyone to read. Now go write your own browser from scratch. See you in a few years.
Software development is an investment of time. It's utter hubris to imagine that what you're doing is so special that nobody could clone it without looking at your source, or even that it would make their job that much easier without an actionable (and easily detectable) amount of cut and paste.

I deeply disagree with most answers above.
It's true that every software can be stolen despite of obfuscation but, at least, it makes harder to extract and reuse individual parts of the software and that is the point.
Maybe it's cheaper and less risky to use an obfuscation than leaving the code open and fighting at court after somebody stole the best parts of our software and made dangerous concurrency.
Unobfuscated code whispers:
Come on, analyze me, reuse me. Maybe you could make a better software using me.
Obfuscated code says:
Go away dude. It's cheaper to use your own ideas than trying to crack me.

You are going to be fighting a losing battle if you try to obfuscate your code in the hopes of someone not stealing it. You may stop the casual browser from getting at it, but someone dedicated would almost certainly be able to overcome any measure you use.
In the past I have seen people do several things:
Paste a lot of whitespace at the top of the page with a message telling people that the code is unavailable, when in actuality you just need to scroll down a few pages to get at it.
Running it through an encoder of some kind, this is so so useful as it can just be run through the decoder.
Another method is to reduce variable names to one character and remove whitespace (this is also an efficiency thing).
There are many other methods.
In the end, your efforts are only likely to stop the casual browser from seeing your stuff. If someone dedicated comes along then there is not much you will be able to do. You will have to live with this.
My advice would be to make a really awesome product that attracts the most people and beat off any competition by having the best product/service/community and not the most obfuscated code.

You're always faced with the fact that any user that comes to your webpage will download some working version of your Javascript source. They will have the source code. Obfuscating it may make it very difficult to be reused by someone with the intent to steal your hard work. However, in many cases someone can even reuse the obfuscated source! Or in the worst case they can unravel it by hand and eventually comprehend it.
An example of a situation like yours might be Google Maps. The Javascript source is clearly obfuscated. However, for really private/sensitive logic they push the data to the server and have the server process that information using XMLHttpRequests (AJAX). With this design you have the important parts on the server side, much more tightly controlled.

That's probably about the best you can do. Just be aware that anybody with enough dedication, can probably de-obfuscate your program. Just make sure you're comfortable with that before embarking on your project. I think the biggest problem with this would be to control who's using it on their site. If somebody goes to a site with your code on it, and likes what it does, it doesn't matter that they don't understand what the code does, or can't read it, when they can just copy the code, and use it on their own site.

A obfuscator won't help you at all if someone wants to figure out the code. The code still exists on the client machine and they can grab a copy of it and study it at their leisure.
There is simply no way to hide code written in Javascript since the source code has to be handed to the browser for execution.
If you want to hide your code, you have the following options:
1) Use an environment where compiled code (not source) is downloaded to the client, e.g. Flash or Silverlight. I'm not even sure that's foolproof, but it's certainly much better than Javascript.
2) Have a back end on the server side that does the work and a thin client that just makes requests to the server.

I'd say yes, it's enough if you also make sure than you compress the code as well using a tool like Dean Edward's Packer or similar. If you think about what is possible with tools like .NET Reflector in terms of reverse engineering compiled code / IL in .NET, you realize that there's nothing you can do to completely protect your investment.
On the other hand, remember that folks who release their source code also seem to make do quite nicely anyway - it's their experience that people want more than their intellectual property.

code obfuscator is enough for something that needs minimal protection, but I think it will definitely not enough to really protect you. if you are patient you can realy de-mangle the whole thing.. and i'm sure there are programs to do it for you.
That being said, you can't stop anyone from pirating your stuff because they'll eventually will break any kind of protection you create anyway. and it is espcially easy in scripted language where the code is not compiled.
If you are using some other language, maybe java or .NET, You can try doing things like "calling home" to verify that a license number matches a given url. Which works if you your app is some sort of online app that is going to be connected online all the time. But having access to the source, people can easily bypass that part.
In short, javascript is a poor choice for what you are doing.
A step up from what you are doing is maybe using a webservice backend to get your data. Let the webservice handle the authentication/verification process. Requires a bit of work to make sure it is bulletproof, but it might work

If this is for a website, which by its very nature puts viewing of its code one menu click away, is there really any reason to hide anything? If someone wants to steal your code they will most likely go through the effort of making even the most mangled code human readable. Look at commercial websites, they don't obfuscate their code, and no one goes out and steals code from the google apps. If you are really worried about code theft, I would argue for writing it in some other compiled language. (which does of course destroy the whole webapp thing...) Even then, you aren't totally safe, there are many de-compilers out there.
So really, there is no way to do what you want in the face of anyone with sufficient motivation.