Logs for the RingoJS IRC channel,
as logged by ringostarr.
2011-02-04
[03:07] <oravecz> I haven't used JST, but I find his complaints about TrimPath unfounded. I mean, he prefers JSP to Velocity in syntax!? The nice thing is they are both options that you can use with RingoJS today.
[11:37] <hannesw> oravecz, mschwartz maybe you're right, there shouldn't be a templating framework in ringo (core)
[11:38] <hannesw> I actually like the idea of just getting rid of it :)
[11:58] <hannesw> ok, I'm really sympathizing with the idea of removing skins altogether
[11:59] <hannesw> let me know if you have objections/concerns.
[12:16] <mcepl> if there will be a good documentation for at least one "recommended" template/skin system, why not.
[12:16] <mcepl> Do one thing and do it well!
[12:31] <hannesw> also thinking about whether to put remaining JSGI utilities into ringo/jsgi/* or a single ringo/utils/jsgi module
[13:05] <botic> i saw this for the first time and found nothing in the group or irc logs: exports.setup = function () { ... } in context of unit testing. anyone here with a short explanation? if i run a test, it isn't executed...
[13:07] <botic> https://gist.github.com/811038 --> output is "Hello" without "Setup"
[13:57] <botic> arghhh, setUp != setup... https://github.com/ringo/ringojs/blob/master/modules/test.js#L205
[13:59] <botic> okay, now working fine. and with this code in zip.js it makes sense in the common.js unit test: require("./common").setup(exports, path, repo);
[15:27] <mschwartz> oravecz: those JST templates... his blog entry is quite old... maybe TrimPath is better these days.
[15:27] <mschwartz> my own preference is to not hide what's really going on in the templates with some wrapper kind of syntax
[15:27] <mschwartz> like <template: if>
[15:27] <mschwartz> instead of <% if
[15:28] <mschwartz> for the work I do, there's a whole production team that does HTML and styling (CSS) and they write JS
[15:28] <mschwartz> the JSP syntax works extremely well for them
[15:28] <mschwartz> as far as templates in the core engine
[15:28] <mschwartz> I'm not discouraging it in the least
[15:28] <mschwartz> if there are 100 commonJS compaitble implementations at some point
[15:29] <mschwartz> the differentiator will be the things that are unique to each one
[15:29] <mschwartz> if RingoJS has some built in templating that is written in Java and has super high performance compared to the others
[15:29] <mschwartz> that would be a differentiator
[15:29] <mschwartz> I wouldn't presume to decide what should go in ringojs tho
[15:30] <mschwartz> Anyhow, I've written 7 months/articles for JSMag about helma 1.7
[15:30] <mschwartz> I think #8 will be a wrap up
[15:30] <mschwartz> and I will continue my series by writing about ringojs
[15:31] <mschwartz> I don't fully understand the love for NodeJS
[15:31] <mschwartz> I would think ringojs would be the superior platform
[15:32] <mschwartz> just for all the Java classes you can include and script
[15:32] <mschwartz> ease of installation
[15:32] <mschwartz> and that it will use all the cores of my CPU and the hyperthreads, too
[16:14] <oravecz> hannesw: we have built a large site based on skins. If skins went away, at the very least perhaps you could fork it to an add-on module, but not give it further development.
[16:14] <mschwartz> is this a ringojs site using skins?
[16:15] <oravecz> I like ringo/jsgi. Seems like jsgi deserves a bit more love that being a util class. :)
[16:16] <oravecz> yes
[16:17] <mschwartz> what kind of app?
[16:17] <oravecz> social networking site
[16:17] <mschwartz> sweet
[16:17] <mschwartz> I'm just finishing a CMS using Helma 1.7
[16:18] <oravecz> it was a $1M site for a client, but they are still working on branding and launch details
[16:18] <mschwartz> wow
[16:18] <mschwartz> very nice
[16:18] <oravecz> We looked at Narwhal early on, but RingoJS was much easier to get started with.
[16:19] <mschwartz> what about performance?
[16:19] <oravecz> The architecture allows for auto-clustering. We run on EC2.
[16:19] <mschwartz> the clustering being custom code you wrote
[16:20] <mschwartz> the CMS I'm doing runs on EC2 as well
[16:20] <oravecz> No, we use Hazelcast as a memcache layer and Elastic Search as our datastore.
[16:20] <mschwartz> We've done probably 25 commercial sites with the CMS already
[16:20] <oravecz> Both of those products auto-cluster
[16:20] <mschwartz> neat
[16:21] <mschwartz> and you can deploy "n" ringojs servers and it all works
[16:22] <oravecz> yes
[16:24] <oravecz> we started out using mongodb as the database, but we needed Lucene-based searching, so it didn't make sense to store the data twice. Using ElasticSearch was the big win, as it is distributed Lucene that persists JSON objects with all the searching goodness that comes with Lucene.
[16:24] <mschwartz> understood
[16:24] <mschwartz> amazon is kicking some serious ass
[16:24] <mschwartz> frequent newsletters from them lately
[16:24] <mschwartz> each one announcing a major new product offering
[16:25] <mschwartz> what do you use to manage your setup on amazon?
[16:26] <oravecz> I use scalr.net
[16:30] <mschwartz> interesting
[16:31] <mschwartz> we have our own custom software to run our amazon stuff
[16:31] <mschwartz> are you familiar with the command line tools for linux?
[16:31] <mschwartz> ec2-describe-instances, and so on?
[16:32] <mschwartz> turns out they're all shell scripts
[16:32] <mschwartz> and they all invoke /usr/bin/ec2-cmd
[16:32] <mschwartz> and the last line of that script is:
[16:33] <mschwartz> java $EC2_JVM_ARGS $cygprop -classpath "$CP" com.amazon.aes.webservices.client.cmd.$CMD "$@"
[16:33] <mschwartz> I dropped that jar into helma's lib/ext dir
[16:33] <mschwartz> and was trivially able to call all the functions
[16:34] <mschwartz> I don't know ringojs that well yet
[16:34] <mschwartz> but you can probably do the same
[16:40] <oravecz> there is also the AWS SDK which exposes all functionality from Java. They have other bindings as well.
[16:41] <oravecz> And, yes, you can call these from inside of your Ringo App if you had that need.
[16:42] <oravecz> Last week, I used the AWS SDK to write a Maven deploy task to beanstalk. Allows us to deploy to dev or qa cloud servers right as part of our maven build process (including continuous integration servers)
[16:43] <mschwartz> I really wish xml would go away
[16:57] <botic> even w3c moves on and extends the current rdf spec with rdf/json support - so there is some hope even for the xml/soap-nerdfarm w3c ;-)
[16:58] <mschwartz> haha
[16:58] <mschwartz> xml is just a waste of time
[16:58] <mschwartz> the content-length is larger than json
[16:58] <mschwartz> and it's better to have a single robust standard than having to support dozens