Before you start developing something useful in Node.js, what's your process? Do you create tests on VowJS, Expresso? Do you use Selenium tests? When?
I'm interested in gaining a nice workflow to develop all my node.js applications similar to Rails (Cucumber, Rspec, Code).
Sorry for the amount of questions.
Let me know how it works out with you.
The first thing I do is to write some documentation or do some wireframes. It helps to visualize what do I want to implement.
Then I code the interface/skeleton of my module/application, without implementations.
Then I add specs and tests using testosterone (although vows and expresso are more popular options) and I make them pass by implementing them.
If you find that a private method needs to be tested (it deals with I/O, has complex logic ...) move it to a another class and test it independently.
Stub your I/O calls as much as you can. Tests will run faster and you will not have to deal with side effects. I recommend gently.
My testing methodology isn't up the snuff as in for example Java/Junit and I should really work more on this(improve). I should really practice TDD more.
I played a little bit with expresso and liked to the fact that you could generate code coverage reports. What I thought was missing was something like #before #beforeclass #after which you can find in java.
I also played a bit with nodeunit which does have setup/teardown. I still like to play a little bit more with this framework.
I don't like the vowjs syntax, but it is very popular BDD framework, so maybe I should use it (more) to get sold like a lot of other users. But for now I am going to dismiss vowjs.
I also played with zombie.js a litle bit which is also pretty cool. I also lately saw another cool testing framework which I can't remember the name, but there are luckily enough options to do testing in node.js.
The only thing I don't like is that the integration with IDE is not up to snuff in my opinion. The IDE I had for Java cannot be compared with what I have found for node.js, but I think with a little bit effort I can make a more useful programming environment. I will try and keep you guys informed about this progress.
P.S: But what I do like a lot is the npm package manager. When you compare it to for example maven you just say wow. I still has some minor bugs because it is still a young project. But still npm is very good in my opinion!
Related
I am not a completely inexperienced developer, but I often find myself struggling with tools and workflow related questions due to not understanding the related compilation process well at all. I have worked with FlashDevelop before, and with Haxe, but one simple thing that I’ve never understood is what occurs when choosing a specific "project type" for a new project.
The primary reason I want to work with Haxe is to be able to more easily target multiple platforms, but I am very new to this. I’d like to make a play-project, a game, with the purpose of learning. One thing I would definitely like to get more experience with is the process and pitfalls of simultaneously targeting web-host-able platforms like Flash and HTML5, tablets, and potentially one day, consoles, etc. In addition, I’m told that targeting Neko can make early-game debugging easier. Finally, should I have the bulk of my 3rd party libraries chosen before deciding on this, or will all of these project types allow me roughly the same flexibility on this as well?
With that in mind, even though I have a rudimentary understanding of the differences between Flash, OpenFL, and Lime, I don’t know which project type to choose to get the best balance of flexibility and ease of setup. I found one answer that seemed to indicate that adding a second target isn’t that difficult. My instinct is to use the OpenFL Project because I have AS3 experience, but I’m not entirely in love with the Flash-centric structure of building games using the display list. Might I be better off just starting with the Haxe “Empty Project” and learning to set it all up myself?
Basically I’d just like to understand what FlashDevlop projects are, and how do I chose the appropriate one to start with Haxe, without losing flexibility to add more targets and various libraries later on.
I hope I phrased that well and that it is an appropriate question. Thank you!
Start with OpenFl project. Haxe is a language that allows you to compile your code to other language(c++,as3,js...). But it's Lime or other frameworks that make it work in all those platforms(c). OpenFl is build over Lime. OpenFl implements all the flash API, so if you know As3 that's a great place to start. You can start there implementing things and getting to know the language. You can start programming immediately, but it's cool to learn all the other cool features that as3 doesn't have.
You have other frameworks, but not all let you export to all platforms.
some popular frameworks are
http://snowkit.org/2014/09/20/about-snowkit/
http://getflambe.com/
I use openFL because I think its the easiest to use, and I think it has the biggest community.
My personal experience, I never had an experience as great as OpenFl. Flash is awesome and OpenFl is like flash on steroids. As any framework you need to know how to use it to get the most out of it.
Best of lucks!
There is a repository of tests for the Mozilla addons site, although it's written using Selenium. I'd like to know if there are any real-world examples available for Watir, so I can see how the framework is implemented by professionals?
This is a more general question about how one goes about building a suite of tests for a website in Watir. On a superficial level, one can write a bunch of seperate .rb files with crude error reporting and fire them all off; but I'd like to know more about writing actual classes and proper test structures that raise issues and return reports. How is this done? Are there any books on this? Tutorials?
Check out WatirMelonCucumber - a set of watir-webdriver tests against google and bing, and also EtsyWatirWebDriver - a set of watir-webdriver tests against Etsy.com
The watir Wiki has a selection of tutorials, examples etc as well.
Start Here
Learning More
Wiki homepage
Those are however fairly basic and don't get into the 'how to organize things' level.
In that case there are a number of frameworks in various states of development. The most active ones are I think are perhaps Taza, and QA Robusta. Each of them approaches things a little differently. QA Robusta is wrapped a bit around Minitest (if I understand things right) and provides it's own reporting. I'm still learning about Taza so can't really comment on it much. I also recall hearing about a 'WatirSpash' gem/framework that was discussed in a recent watir podcast which is designed to help watir use along with RSpec (and I might presume Cucumber)
If you are a BDD/Spec-by-example sort, then you may want to use either (or both) RSpec or Cucumber perhaps in combination with the WatirSpash gem as a way to organize and describe you tests, and then implement the actual test code via Watir, In that case you would likely be using the HTML based reports that can be generated by RSpec/Cucumber instead of rolling your own or depending on a watir framework for the reporting.
More Watir frameworks:
https://github.com/jarmo/WatirSplash
https://cyberconnect.biz/opensource/qa_robusta.html
Not in active development:
https://github.com/scudco/taza
https://github.com/bret/watircraft
QA Robusta most likely will not have too many new features added but will be supported. Instead you may want to check out whirlwind. Whirlwind uses similar concepts as other frameworks such as qa_robusta and taza, but is lighter weight and tailored around cucumber/rspec. See the walk through for a google search example.
I've been looking into Spock and I've had experience with FitNesse. I'm wondering how would people choose one over the other - if they appear to be addressing the same or similar problem space.
Also for the folks who have been using Spock or other groovy code for tests, do you see any noticeable performance degradation? Tests are supposed to give immediate feedback - as we know that if the tests take longer to run, the developer tends to run them less frequently - so I'm wondering if the reduction in speed of test execution has had any impact in the real world.
Thanks
I am no FitNesse guy, so please take what I say with a grain of salt. To me it seems what FitNesse is trying to do is to provide a programming language independent environment to specify tests. They use it to have a more visual interface with the programmer. In Spock a Groovy ast transform is used to transform the table into a groovy program.
Since you basically stay in a programming language it is in Spock more easy to realize more complicated test setups. As a result you often seem to have to write fixture code in FitNesse.
I personally don't need a test execution button, I like the direct approach. I like not having to take of even more classes, only to enable testing and I like looking at the code directly. For example I want to just execute my test from the command line, not from a web interface. That is surely possible in FitNesse too, but as a result the whole visual thing FitNesse is trying to give the user is just ballast for me. That's why I would choose Spock over FitNesse.
The advantage of the language agnostic approach is of course, that a lot of test specifications can be used for Java and for .Net. so if that is a requirement for you, you may want to judge different. It usually is not to me.
As for performance, I would not worry too much about that part.
Hey guys, I'm very excited about how experienced I am in programming.
The first, working program that I have written, was in 2004 with C. Since this I have tried many programming languages, now got stuck with php. Currently I'm working as a web-developer, and everyones pleased with the work I do. Except me :) Thats the reason why i want to know, how high my experience and my knowledge is.
Could you tell me, some tips, tricks, test, or anything, on what I can see how much I need to learn and practice to get a mastermind in programming? (at first place in php)
I'm also a programmer who doesn't like to stagnate, so perhaps I can offer a few tips:
1) What's your weakest area? Networking? Graphics? Regex? What is the one area that if someone asked you "I need a program that can do X" and that X scares you what is it. Now study as much as you can on that subject. Hack out a few prototypes and make it so that you understand it allot better. I used to hate Regex commands, now I use them whenever I can.
2) Study "different" languages. I'd recommend learning a "functional" language such as Erlang, Lisp, or perhaps certain aspects of Python. Get a book on "functional programming" and read it through, and then think how you can apply these concepts to your current work. Start using map() and filter() in python instead of for loops, etc.
3) If you're doing web programming, get yourself a massive set of data and start doing some number crunching. A while back I was playing EVE Online, so I fired up SQL Server Express and hacked out some market analysis routines in it. It was around 4 GB of data the server crunched through, but I learned allot about SQL Server in the mean time.
I recently was watching a lecture on Lisp and the Professor said: "Computer Science is not about computers and not about science. It's about knowledge, and how to manipulate that knowledge to obtain more knowledge" So true, so the more tools you have for manipulating and gaining knowledge, the better programmer you'll be.
Start a new programming project and take your time to make every single aspect of it as good as possible.
Use git or Mercurial for source control. Use submodules (or whatever the Mercurial equivalent is) to manage external frameworks. Set up post-commit hooks to run your unit tests and zip up your executable. Use new branches for everything and do octopus-merges to get them all back into a single branch.
Script everything you do. Deploying a new version of your app (including website updates!) should be as simple as running a single script.
Make your app 100% localized. Deploying in a new language should be as easy as sending a strings file out to a volunteer to get translated, then popping that translated file into your source code, no additional work needed.
Optimize, optimize, optimize. Spend the extra week to make your app load 100ms faster.
Refactor, refactor, refactor. Don't just go for orthogonality and abstraction, aim for pure code beauty. Using your classes should be like using Duplo blocks, they just snap into place with not an error in sight.
Unit test everything. 100% coverage. Don't let a single regression go unannounced. Automate the entire test suite so that you can't promote your code without all the tests passing.
Put your app in the cloud. If you're writing something for the desktop or a mobile device, give your users a way to sync their data to a website. Write that website. If your project is web-based, give your users a mobile or desktop front-end to access their accounts.
Accessibility. Handicapped users should be thrilled with the care you put into designing your app.
Keep in mind that if you do everything I listed here, you'll never ship, but you'll be a well-rounded a developer, an asset to most any team.
We're writing a large production system in Java, and I'm considering whether or not we can write some of the components in one of the JVM-based dynamic languages. Groovy appears to be the best choice from the Java interoperability standpoint. But is the Groovy implementation reliable enough to use in production (I would assume so), and is the Groovy language specification itself stable enough so that we aren't going to have to revise our production code substantially in a year or two? What are your experiences?
Summary (5/30/09): Good comments, the sense I get is that you should be cautious in adopting Groovy for mission-critical production use, it's fine for ancillary usages like putting together test cases, and there's a middle ground where it's probably fine but do your homework first. Performance is an issue, which needs to be balanced against the increase in developer productivity. Bill and Ichorus have equally helpful answers based on Groovy use, so it was a coin toss.
Update (12/3/09): More recently I've been taking a serious look at Scala, another JVM language. It was designed and implemented by Martin Odersky, the original author of the current javac compiler and the co-designer of Java Generics. Scala is a strongly typed, but uses type inferencing to strip out a lot of boilerplate. It's a nice blend of object-oriented and functional programming. James Gosling likes it. James Strachan, the author of Groovy, likes it too. And Odersky's experience writing javac means Scala's raw performance is not far from Java's, which is impressive.
Update (4/26/11): Take a look at Groovy++, a statically typed extension of Groovy, which has performance equivalent to Java. Looks very interesting.
Edit: Here almost four years later and Groovy has become much more solid.
I can wholeheartedly recommend it for production grade projects.
I've been using Groovy to support production applications for a while and for that purpose it is stable enough. As for actually having Groovy in bona fide production code; I don't think I would do that. Groovy does too many surprising things. It has gotten much better in this regard over the past year or so, but every once in awhile I will run into a bug that is a bit difficult to track down because of the generated code (my issues seem to have revolved around scoping).
I have gotten away from Groovy (though the stuff that we use that is simple and solid is still around) and have used Python (jython implementation), which has been far more predictable in my opinion. Also, python trumps Groovy in readability.
You can write some very interesting code in Groovy with closures and operator overloading and whatnot.
These languages are used for convenience and speed on ancillary code...stuff that can be switched out on the fly if need be. None of it is in production. I don't think I would put either in production unless it was as a stopgap to get something critical out of the door in a major hurry or as a proof of concept or prototype.
And in the case of putting it in actual production, it would have to be in the most dire of circumstances and I would assign someone to rewrite it in pure Java for the next release. I am 98% sure that either would be fine in production but that 2% is too much unnecessary risk.
We've got several production apps running on Grails (using Groovy as the language). So far, no issues have resulted. As for JVM compatibility, take a look at how little the JVM byte-code has changed in the last 5 years... like 1 instruction was added, and none were made obselete.
Will new versions of Groovy come out in the next year? Yes. Will you be required to change to them? No. Though you might want to, 1.6 is a huge speed improvement.
Which brings us to the major drawback of Groovy, the speed issue. Obviously, Groovy is slower than straight Java. The current number are up to 10 TIMES slower, for certain actions. That said, is your CPU the bottleneck in your app? For us, it's mostly DB access and latency. If it's the same for you, what matter if the CPU spends 200ms processing the page request instead of 35ms?
Is that the only problem with Groovy? Nope. Dynamic languages have refactoring difficulties, since there isn't necessarily a complete class specification anywhere in the code. However, this is partially balanced by the smaller code-size which makes it easier to find the places to modify the code.
Anyway, Groovy is a perfectly fine language for production uses. Mix it with Java for your "critical" code, if you fear the reliability. That's the BEST part of Groovy... how easy it mixes with Java classes.
I'm currently exploring using Groovy for only writing unit tests. This has the effects of
Allowing the potentially tedious part of writing tests to be done in a syntax that is a bit simpler than Java.
Keeps the Groovy code out of production.
Allows a large portion of the code base to be written in a non-Java language.
Of course, we haven't started yet, but this is at least my way of attempting to introduce alternate JVM languages to our new projects (and possibly existing ones). I have the same concerns you do, and even more so around performance than stability.
Scripting languages evolve "too fast" in the aspect of syntactic features.
If you want a language for the JVM that will stay compatible for
many years,
Java is your only choice ;)
By the way, I don't think that the readability of code is
ensured by a scripting language automatically.
We used Grails/Groovy as our primary backend at my previous company, and from that experience I'd say that I would choose Groovy over Java in most circumstances I am likely to encounter, since it interoperates with Java seamlessly and is otherwise more fun and expressive. Additionally I would expect the database would almost always be the bottleneck of my application rather than language performance, and we didn't encounter any stability issues/bugs with groovy as far as I recall.
But personally it's usually not about Groovy vs Java for me in most cases -- it's about Groovy/Java + available libraries vs. other languages like Python/Jython/JavaScript/Ruby + available libraries. And there are a lot of other considerations there such as strength of community, maturity of relevant technologies for your particular application, etc. In particular, for web development, Grails was decent, but the community seemed lacking. My overall opinion is that I would use python or Node.js going forward. If I needed the JVM I'd use a jython-compatible python web development environment.
I've been playing with Groovy for a month or so. The simplicity is awesome, and the dynamic language features are really cool too. However, speed is definitely an issue. Also, the groovy console really sucks. You cannot do things that you can do e.g. in python. Every once in a while I have to restart the console, reimport, things, etc. It also keeps forgetting the values I put in the variables while in the console mode; somehow mystically they go out of scope. (Is it because of the JVM? I don't know.) I cannot come up with an example from the top of my head, but the behavior I get in the Groovy console is different from the behavior I get in the Grails console, and is different from what I get by just writing code in a script.
A few more warnings. Note that Groovy is almost, but not 100% compatible with Java. For example, this will not compile:
public class HelloWorld {
public static void main(String args[]) {
System.out.println( "Hello, world!\n");
}
}
Also take a look at How to get classpath in Groovy?