Message-ID: <132750618.5859.1369531526752.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_5858_2001702360.1369531526751" ------=_Part_5858_2001702360.1369531526751 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Tynamo is model-driven, full-stack web framewo= rk based on Apache Tapestry 5.
Tynamo's mission is to
|Quick status update|
CRUD+S is finally here. tapestry-model 0= .5.0 comes built-in with hibernatesearch for hibernate and elasticsearc= h for JPA!
=20 =20 =20
Ye= s, we just might have forgotten to announce "a few" releases we'v= e made. We got busy, what can you say? Besides our marketing dudes never do= anything anyway. Let's start the year with a bang and correct the situatio= n right now (after taking the marketing department behind the shed). Here's= a recap of the previously unannounced releases we've made in the last four= months:
We finally implemented a built-in full= text search. The Hibernate version is using HibernateSearch because it's a= h so automatic and nice. Only thing is that it's local only. For the JPA ve= rsion, we fully integrated ElasticSearch, the best thing since full-text br= ead. I dare say our integration is better than the one that Play framework = has to offer. It seamlessly integrates with SQL-based search and is easy to= extend. tapestry-model continues to be better suited only for the more exp= erienced Tapestry users. One day we'll write proper documentation for it an= d surprise you all.
A fix for TYNAMO-183 forced our hand because of some dependencies o= n 5.3 so we decided to push out 0.5.0 a bit early. We'll get the rest of th= e improvements in later. We are also dropping support for T5.0/5.1 but hey = it's open source. If you find a bug in the earlier releases, send it to us = and we'll patch it.
TYNAMO-129, or rememberMe with rollingtokens ma= de it as a new submodule of federatedaccounts. There's just no reason to us= e those puny, insecure and ordinary remember me cookies anymore. More at my= blog post on RememberMe with rolling tokens.
First, the younger JPA version of the well battle-tested seede= ntity library pulled next to the hibernate-seedentity, turned her head and = waved, then sprinted ahead laughing, leaving the hibernate guy sobbing in d= ust (in terms of features).
I stil= l think it's the coolest little library out there and just wouldn't be poss= ible to implement without the lovely distributed configuration of Tapestry.= You aren't still modifying your html text content in an offline text edito= r, are you? Now I just need to integrate conversation and inline image supp= ort.
Want to secure your data instances? Thi= s one works so well it's annoying.
In the past five = years, I worked on a number of greenfield projects. In three out of four, w= e ended up choosing Grails - it is very hard to deny the market & minds= hare , the expansive documentation, the big name company behind the project= , the large community, a massive number of plugins (for pretty much anythin= g that you'd want), the end-to-end stack (so, you don't have to choose your= ORM, DI, etc) and the ease of getting started with a Grails project. =
However, after working on a couple of these Grails projects for = a few years, the latest project I got involved with , I chose Tapestry. In = some cases, I've missed some of the niceties that Grails brings out of the = box, but without too much effort I've been able to replicate them fairly ea= sily.
The biggest reasons for picking Tapestry over Grails o= n this latest project have been:
On the first issue, if you wi= ll be using Groovy for your pages, you will be in the same boat as Grails. = Personally, I wouldn't recommend it - Tapestry already pushes the envelope = on Java quite a bit, so your Java code ends up being very short and sweet a= lready. In the past, I had attempted to use Scala in a tapestry app, and en= ded up having to just deal w/ some of the mismatches between the language a= nd the framework and my pages ended up looking up like the same old java pa= ges I would have had but with a different syntax.
On the sec= ond issue, there is the grails resources plugin that tries to pull resource= s kinda like Tapestry, but using it requires this artificial separation int= o resource bundles which seems to be a PITA and somewhat mind bending.=
On the abundance of Grails plugins - after using a bunch for the= projects I was working on, it turned out that many were not well maintaine= d so we hadto take over and maintain them ourselves. Sometimes, they're a g= ood starting point, but in the end ended up less of a factor than I initial= ly thought.
I originally very much enjoyed the Grails build = system (running on top of Gradle); however, with a pretty simple project se= tup, Maven seems to bejust as straightforward. If you wanted Gradle, you co= uld use that for your Tapestry app, and be on-par w/ Grails.
On the latest project that I chose Tapestry for , I have been very happy w= ith my choice. On a few occasions I've run into some frustrations (e.g. for= rendering emails, I ended up having to use Freemarker, whereas with Grails= the template rendering for emails comes for 'free' ; I had to build my own= equivalent of the Grails "console" plugin where you can run Groo= vy commands inside of your running application); however, in all cases, the= solution has turned out to be more elegant than I had expected (albeit, it= required deeper tweaks in the framework than I had expected).
Persistent login cookies are the = cookies that are stored with your browser when you click the "remember= me" button on the login form. I would like to be able to say that suc= h cookies are obselete, and we have a better way of handling user logins, b= ut they aren't, and we don't.
The following recipe for persi= stent cookies requires no crypto more powerful than a good random number ge= nerator.
With all this in mind, I've always implemented remembe= rMe based on rolling tokens in the various web applications I've worked on.= However, I've never attempted to provide it as a reusable module until one= day a few months ago while I was working on federatedaccounts it hit me: r= olling tokens can be thought of as just another "remote" authenti= cation provider that can be federated with the main account. For some month= s now, we've happily been using tynamo-federatedaccounts-rollingtokens in p= roduction. I added some quick documentation for it at the end of the generi= c tynamo-federat= edaccounts guide, have (secure) fun with it!
Release notes, concisely:
Read more at=C2= =A0tapestry-routing guid= e and enjoy!
Read more at tapestr= y-security guide and enjoy,
And be assured that EntityManager.merge() would fail even if=
somebody manually replaced the entity id somewhere along the way? Wouldn't=
it be equally cool if you could just do EntityManager.find(Account.class, =
null) to fetch the right Account for the currently logged-in user? If secur=
ing data instances have been causing gray hair for you before and you happe=
n to be using JPA, you should definitely checkout Tynamo's latest module, <=
On a related note, if you happen to live in SF Bay Area, I'll b= e talking about ERBAC, federated accounts, tapestry-security and using Shir= o in modern Java web applications in an upcoming Shiro JUG meet-up this Wednesday, graciously sponsored by St= ormpath, Inc.!
"Today I found myself thinking again of what I see=
as two distinct cultures in the development world: Hackers and Enterprise =
Developers. This really isn=E2=80=99t any kind of a rant just an observatio=
n that I=E2=80=99ve been thinking over lately.
Hackers are r= eally bleeding edge. They have no problem using the commandline, using mult= iple languages, or contributing back to open source. They=E2=80=99ll find a= nd fix bugs in the opensource software they use and issue pull requests fre= quently. They=E2=80=99ll always be willing to use new tools that help them = produce better software when there might not even be any good IDE support. = Finally, they=E2=80=99re always constantly investigating new technologies a= nd techniques to give them a competitive edge in the world.
= Now when I say hacker I don=E2=80=99t mean someone who just hacks lots of r= andom shit together and calls it a day (that kind of developer isn=E2=80=99= t good for anyone). Just someone who isn=E2=80=99t afraid to shake up the s= tatus quo, isn=E2=80=99t afraid to be a bit different and go against the gr= ain. They=E2=80=99re the polar opposite of enterprise developers.
Enterprise Developers on the other hand are fairly conservative with = their software development methodology. I=E2=80=99m not saying that a lack = of standards is a good thing, but enterprise developers want standards for = doing everything and they want it standardized across the company. If there= isn=E2=80=99t IDE support for a tool they=E2=80=99ll refuse to use it. Wan= t to use mongodb, riak, etc? Not unless there=E2=80=99s a fancy GUI client = for interacting with it. If they find a bug they=E2=80=99ll back away from = the framework they=E2=80=99re using and simply declare that the company sho= uldn=E2=80=99t use the framework until the bug is fixed externally. I find = this group prefers to play it safe and work on solidifying their existing p= ractices rather than explore new ideas.
Now don=E2=80=99t g= et me wrong, this isn=E2=80=99t another rant on IDEs or developers who don= =E2=80=99t use the command line. But give me a couple days in any organizat= ion and I can quickly point out who the Hackers and Enterprise Developers a= re."
It's also noteworthy to point out that at least from m= y experience, the average enterprise developer typically makes much more th= an the average hacker. So who's really the smart one, eh? Read the whole po= st at: http://www.java= codegeeks.com/2012/03/tale-of-two-cultures-hackers-and.html
Check out the tap= estry-security guide for more information and enjoy!
Oh and btw, = we had also previously released but hadn't announced a bug-fix release 0.1.= 2 for the exceptionpage module, that tapestry-security uses for exception h= andling. The lone issue was:
Read more about the exceptionpa= ge module from tap= estry-exceptionpage guide
Hey XXX, somehow our conversation from the other day got stuck i= n my head. First, I have to say that it looks to me you are putting too muc= h emphasis on technologies. You should let your engineers and the business = needs guide your technological choices, not the other way around. It's goin= g to be expensive to rewrite your application later if you need to, but so = what, it's going to be much more expensive to change the business if your c= urrent one doesn't work, and yet you are still doing it. Unless you want to= make it your core competency to implement the solutions using the chosen t= echnologies, you have to trust and rely on your engineers to make the right= choices for the given problems. What you primarily need from your engineer= s is motivation and experience with one of the reasonably good technologica= l choices and leave it at that. It's difficult to predict the future so whe= ther you pick RoR, Django, Play or some other hot technology today, you don= 't know if it'll be a success anymore a few years down the road.
On the popularity of Tapestry, you asked "so how come nobody uses= it?" By many measures, Java is the most popular language in the world= but very few think of it as cool or hype it. The hyped Java is today prono= unced "Android" or "Scala". Tapestry is a good example = of what's left after the hype has deflated. Ruby on Rails is a fairly succe= ssful and popular framework, yet it was much, much more popular six years a= go than it is today. In the world of Java, Tapestry, Play or Lift are still= newcomers compared to such behemoths as Struts (one of the original web fr= ameworks in Java). Java is just popular and old enough that the space is fr= agmented. The good news is that beyond "just" the web layer, you = have libraries implemented in Java for almost any imaginable purpose you ca= n simply take into use. Tapestry, or Java are not always good choices for w= eb applications, because the needs for most of the websites are simple, so = a simpler language and a simpler framework will not only suffice, but work = better because more people are more productive with it and there may be les= s room for grave mistakes. For lots of applications you simply don't need a= ll of the power Java or the JVM has to offer, but when you do, you really n= eed it. The classic example for this is a highly threaded back-end applicat= ion - if you have a need for it, a typical RoR or Python-based architecture= implements the web layer in the given language, but the back-end architect= ure with a different language. Few other languages and platforms besides Ja= va are comprehensive enough to implement everything from web to the databas= e with the the same language (although certain Microsoft language comes to = mind as an alternative). With RoR, Python or PHP, you pair it with MongoDB = (implemented in C++) or perhaps MySQL (in C++ as well). A Java web framewor= k, you pair with Cassandra, Hadoop, hsqldb or any of the other strong alter= natives based on need, all implemented in Java. It makes it all more comple= x, which is also reflected in the pay grade between a typical Java develope= r and a php developer, or any of the other languages in between. What makes= this even more interesting to you, is that as a business owner you have to= consider the costs so the best solution for you might be finding the most = inexpensive developers that are highly productive with their language of ch= oice.
*** UPDATE ***: A bit after my email, my = friend sent me a link to this great blog post by the Tumblr guys= , to which I just had to reply. Again, I've re-posted the unedited foll= ow-up below. Keep in mind that I'm purposefully making some simplifications= to make my point clear (after all, I'm talking to a business dude). Anybod= y who's battled with scalability issues knows that while theoretical number= s might justify more modest hardware, it's all about building for the worst= -case scenario with plenty of reserve capacity.
Nicely proves my = point, no? :) Anyway, it's a surprisingly honest read about their architect= ure, and shows how most of the time it's all organically grown. They are ge= tting reasonable results with their infrastructure, but still, paying a hea= vy penalty for the suboptimally performing web layer - 500 web servers vers= us 200 database servers, where most of the latter are used for stand-by hig= h availability. In a typical scenario, the bottleneck should almost always = be the database layer, not the web layer. Sharding is a way to get scalabil= ity out of MySQL, but it's far, far away from the highest performing SQL da= tabases. Now, imagine if you could serve the whole database layer with 20 s= ervers instead of 200.
For an all Java implementation with a= n embedded database, it's not uncommon to require 90th percentile response = time within 10ms with at least 1 million page views a day from a single ser= ver. Performance matters (http://docs.codehaus.org/page= s/viewpage.action?pageId=3D190316696).