Message-ID: <1163023486.2648.1386974790226.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_2647_1844091570.1386974790225" ------=_Part_2647_1844091570.1386974790225 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Tynamo's mission is to provide implementations for different asp= ects of a full web application stack that offer reasonable out-of-= the-box functionality and are easy to customize. We are intent on proving t= hat web applications based on Java can simultaneously be high perfo= rming, easy to implement and fun to develop. We leverage existing = technologies where possible and provide integrations with proven, clean and= compact libraries rather than limit ourselves only to standard Java (JSRs)= . Tynamo is both comprehensive and modular so you are free to choose the pa= rts you like from our full stack. And finally, we like Tapestry and our mod= ules use Tapestry IoC extensively.=20 =20
The Tynamo Team.=20
Yes, we just might have forgotten to announce "a few" releases= we've made. We got busy, what can you say? Besides our marketing dudes nev= er do anything anyway. Let's start the year with a bang and correct the sit= uation right now (after taking the marketing department behind the shed). H= ere'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 versio= n is using HibernateSearch because it's ah so automatic and nice. Only thin= g is that it's local only. For the JPA version, we fully integrated Elastic= Search, the best thing since full-text bread. I dare say our integration is= better than the one that Play framework has to offer. It seamlessly integr= ates with SQL-based search and is easy to extend. tapestry-model continues = to be better suited only for the more experienced Tapestry users. One day w= e'll write proper documentation for it and surprise you all.
A fix for TYNAMO-183 forced our hand because = of some dependencies on 5.3 so we decided to push out 0.5.0 a bit early. We= 'll get the rest of the 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 re= leases, 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 seedentity libr= ary pulled next to the hibernate-seedentity, turned her head and waved, the= n sprinted ahead laughing, leaving the hibernate guy sobbing in dust (in te= rms of features).
I still think it's the coolest little library out there and just wouldn'= t be possible to implement without the lovely distributed configuration of = Tapestry. You aren't still modifying your html text content in an offline t= ext editor, are you? Now I just need to integrate conversation and inline i= mage support.
Want to secure your data instances? This one works so well it's annoying= .=20
In the past five years, I worked on a number of greenfield projects.= In three out of four, we ended up choosing Grails - it is very hard to den= y the market & mindshare , the expansive documentation, the big name co= mpany behind the project, the large community, a massive number of plugins = (for pretty much anything that you'd want), the end-to-end stack (so, you d= on'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 fe= w 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 easily= .
The biggest reasons for picking Tapestry over Grails on this latest = project have been:
On the first issue, if you will be using Groovy for your pages, you = will be in the same boat as Grails. Personally, I wouldn't recommend it - T= apestry already pushes the envelope on Java quite a bit, so your Java code = ends up being very short and sweet already. In the past, I had attempted to= use Scala in a tapestry app, and ended up having to just deal w/ some of t= he mismatches between the language and the framework and my pages ended up = looking up like the same old java pages I would have had but with a differe= nt syntax.
On the second issue, there is the grails resources plugin that tries= to pull resources kinda like Tapestry, but using it requires this artifici= al separation into resource bundles which seems to be a PITA and somewhat m= ind bending.
On the abundance of Grails plugins - after using a bunch for the pro= jects I was working on, it turned out that many were not well maintained so= we hadto take over and maintain them ourselves. Sometimes, they're a good = starting point, but in the end ended up less of a factor than I initially t= hought.
I originally very much enjoyed the Grails build system (running on t= op of Gradle); however, with a pretty simple project setup, Maven seems to = bejust as straightforward. If you wanted Gradle, you could use that for you= r Tapestry app, and be on-par w/ Grails.
On the latest project that I chose Tapestry for , I have been very h= appy with 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 ru= n Groovy commands inside of your running application); however, in all case= s, the solution has turned out to be more elegant than I had expected (albe= it, it required deeper tweaks in the framework than I had expected).= p>
Persistent login cookies are the cookies that are stored with your b= rowser when you click the "remember me" button on the login form.= I would like to be able to say that such cookies are obselete, and we have= a better way of handling user logins, but they aren't, and we don't.<= /p>
The following recipe for persistent cookies requires no crypto more = powerful than a good random number generator.
With all this in mind, I've always implemented rememberMe based on rolli= ng tokens in the various web applications I've worked on. However, I've nev= er attempted to provide it as a reusable module until one day a few months = ago while I was working on federatedaccounts it hit me: rolling tokens can = be thought of as just another "remote" authentication provider th= at can be federated with the main account. For some months now, we've happi= ly been using tynamo-federatedaccounts-rollingtokens in production. I added= some quick documentation for it at the end of the generic tynamo-federatedaccounts guide= a>, have (secure) fun with it!=20
Release notes, concisely:
Read more at tap= estry-routing guide and enjoy!=20
Read more at tapestr= y-security guide and enjoy,
And be assured that EntityManager.merge() would fail even if somebody ma=
nually replaced the entity id somewhere along the way? Wouldn't it be equal=
ly cool if you could just do EntityManager.find(Account.class, null) to fet=
ch the right Account for the currently logged-in user? If securing data ins=
tances have been causing gray hair for you before and you happen to be usin=
g JPA, you should definitely checkout Tynamo's latest module, tapestry-security-jpa.
= On a related note, if you happen to live in SF Bay Area, I'll be talking ab= out ERBAC, federated accounts, tapestry-security and using Shiro in modern = Java web applications in an upcoming S= hiro JUG meet-up this Wednesday, graciously sponsored by Stormpath, Inc= .!
"Today I found myself thinking again of what I see as two disti=
nct cultures in the development world: Hackers and Enterprise Developers. T=
his really isn=E2=80=99t any kind of a rant just an observation that I=E2=
=80=99ve been thinking over lately.
Hackers are really bleed= ing edge. They have no problem using the commandline, using multiple langua= ges, or contributing back to open source. They=E2=80=99ll find and fix bugs= in the opensource software they use and issue pull requests frequently. Th= ey=E2=80=99ll always be willing to use new tools that help them produce bet= ter software when there might not even be any good IDE support. Finally, th= ey=E2=80=99re always constantly investigating new technologies and techniqu= es 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 random shit = together and calls it a day (that kind of developer isn=E2=80=99t good for = anyone). Just someone who isn=E2=80=99t afraid to shake up the status quo, = isn=E2=80=99t afraid to be a bit different and go against the grain. They= =E2=80=99re the polar opposite of enterprise developers.
Ent= erprise Developers on the other hand are fairly conservative with their sof= tware development methodology. I=E2=80=99m not saying that a lack of standa= rds is a good thing, but enterprise developers want standards for doing eve= rything 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. Want to us= e mongodb, riak, etc? Not unless there=E2=80=99s a fancy GUI client for int= eracting with it. If they find a bug they=E2=80=99ll back away from the fra= mework they=E2=80=99re using and simply declare that the company shouldn=E2= =80=99t use the framework until the bug is fixed externally. I find this gr= oup prefers to play it safe and work on solidifying their existing practice= s rather than explore new ideas.
Now don=E2=80=99t get me w= rong, 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 organization an= d I can quickly point out who the Hackers and Enterprise Developers are.&qu= ot;
It's also noteworthy to point out that at least from my experience, the = average enterprise developer typically makes much more than the average hac= ker. So who's really the smart one, eh? Read the whole post at: http://www.javacodegeeks.com/2012= /03/tale-of-two-cultures-hackers-and.html=20