2

I really like programming simple things, like solutions for Project Euler, where you can concentrate, write an algorithm, instantly execute, test, verify and change the program until it works. Even for bigger projects I feel I can maintain flow and be very productive as long as I can stay in one IDE (e.g. Eclipse) and everything compiles and starts fast, for example, if it is a Swing GUI.

With the growing focus on web applications and smart phones however, I am forced to set up a web server, juggle a big amount of programming and markup languages (e.g. Javascript, Java, HTML, CSS), different kinds of editors and wait while something is deployed (web server), compiled (GWT, Vaadin) or virtualized (Android). Are there solutions that allow to circumvent those problems?

I know this questions may sound subjective but it is an important issue for me and I think it can benefit many others as well.

P.S.: What I am looking for is a solution to web development which allows staying in one IDE and which allows testing and executing without long waiting for long compiles, deploys, ect.

Konrad Höffner
  • 127
  • 6
  • 2
    Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the [How to Ask page](http://programmers.stackexchange.com/help/how-to-ask) for help clarifying your question, and the [What topics can I ask about here](http://programmers.stackexchange.com/help/on-topic) page. – Robert Harvey Mar 12 '14 at 16:34
  • Try another IDE. –  Mar 12 '14 at 16:42
  • 2
    you got spoiled back in the olden days you had to wait 2 days before you got the result of your program if you were lucky and you didn't make any errors. it forces you to think about your code before running instead of just hitting that run key – ratchet freak Mar 12 '14 at 16:45

2 Answers2

2

As a matter of principal, as the problem gets tougher, the solution gets more complicated - Project Euler is a very safe environment, which poses problems intended specifically to teach you how to solve an issue.

Real-life projects tend to be made up of a lot of issues in the form of features, media, scale, connectivity, front-end, etc.

I don't think you should strive to make solving a real-life problem look like solving an exercise. The best approach, in my opinion, is to solve it one problem at a time.

You can start by breaking your problem to features, starting with a simple one, implementing it, and continuing to the next (BDD style).

This way, with each feature, you can solve the problem in the most simple way you can (continually refactoring it to be DRY and well designed), keeping with small iterations, and manageable "sprints", where you can control which technology you are focusing on at each tier.

This way (and with a little patience), you can solve bigger and bigger problems, learning a lot of technologies along the way, being less concerned about juggling and switching between technologies, IDEs and design problems, and more focused on the problem at hand.

Uri Agassi
  • 1,751
  • 11
  • 18
2

You adress three different topics:

  • switching between different editors
  • switching between different languages
  • build duration

Concerning the editors, the is no reason to use more than one. If you have an IDE, it certainly has html/css/javascript modes. Same thing if you use something like vim/emacs/sublime text/notepad++. I don't see why you should change your editor.

Build duration is a problem in all kind of application. The solution is to use an interpreted language, or to work on individual modules and use TDD. This also allows you to bypass the launch & manual test phase. This requires a bit of initial design to break down & formalize features needed but it is usually pays to do so anyway.

HTML does not really needs to be unit tested. I find it useful to test css adjustment using the browser debug mode. That way you get a quick edit-feedback loop.

Switching between different languages is a problem. You should organize yourself to minimize such switches by focusing on one part at a time. However, with time it will be less and less problematic.

Simon Bergot
  • 7,930
  • 3
  • 35
  • 54