- Warsaw JUG
- Warsaw, Poland
I have given a speech titled: Play!Framework – ewolucja w świecie aplikacji webowych (Play!Framework – evolution in web applications world) dedicated to a Java/Scala web development framework, showing participants some advantages (and disadvantages) of this tool. Play have already been there for a while, so most of you have probably already heard of it.
Presentation was 60 minutes long and I assume there were ~150 participants. I used Prezi as presentation tool and official Play’s screencast to present basic coding patterns.
PlayFramework is a young web development framework for Java and Scala. It throws away some fundamental Java world solutions (like Servlets) in advance to provide extremely robust development environment. This presentation answers to couple basic question each developer would ask about a new framework. It shows PlayFramework’s MVC fundamentals, dynamic reloading and build system.
Full stack web development framework is a subject more for a training than a short lecture, so many topics will be at most just mentioned during 60 minute talk. That’s why I let participants choose topics they want to hear about. Seeing a round of options with small sub-presentation connected to each seemed a great idea for this purpose.
About two weeks after I got a survey filled by participants. Thanks to that I could see how bad idea was to use official PlafFramework’s screencast. On the other hand the second part of the lecture felt a lot better.
You can see the full video at Vimeo.
- listwy w salach
- bogata agenda
- poziom prezentacji
- sprawny net
- niezbyt wypchane sale
- kolejka po lunch
- miejsce (jednak ciasne korytarze, sypiące się łazienki)
Jeśli jesteś zainteresowana(y) udziałem, zajrzyj na stronę hackathonu gdzie możesz zobaczyć obecną listę uczestników, przejrzeć propozycję tematów i oczywiście zapisać się na wydarzenie. Jeśli spodobał Ci się któryś z opisanych już projektów, możesz na tej stronie do niego dołączyć, lub, jeśli wolisz inny temat, zaczekać z wyborem do samego hackathonu. Jeśli masz pomysł na własny projekt strona ułatwi Ci przybliżenie innym uczestnikom Twojego pomysłu i znalezienie chętnych.Aby dzielnie pracujące głowy mogły się skupić nad problemami programistycznymi, a nie nad bardziej przyziemnymi sprawami, zapewnione będą przekąski, ciepły posiłek i napoje, a nawet domowe piwo warzone przez jednego z najlepiej rozpoznawanych domowych piwowarów w Polsce - Pawła Leszczyńskiego. Aby docenić ciężko pracujących hackerów, a z drugiej strony nie zamienić wieczoru w zawody za najlepsze projekty będą na Was czekały 3 bony na książki w Amazonie, oraz w większej ilości Raspberry Pi - komputery niewiele większe od karty kredytowej. Do zobaczenia!
org.apache.tapestry5.plastic.PlasticManager. This we may build using static builder methods in it’s class, e.g.[gist id=”4432985”] Next there’s a place for a delegate (meaning class transforming delegation). For this we will use
org.apache.tapestry5.internal.plastic.StandardDelegateadapter, which brings
Delegateinterface. So now we end up needing a transformer, inside of which we’ll use an advice (
org.apache.tapestry5.plastic.MethodAdvice). See creating and putting them together in the following snippet:[gist id=”4433014”] As you have seen by now, Plastic is a pretty high level, object oriented and well designed tool for modifying classes. Although creating a simple case of adding an advise to a method requires a lot of boilerplate code. In next part we’ll go deeper into the Plastic API.
gradle testwould be natural next step, but still no luck there: [gist id=”b6115bf9b9758b1a2980”] Missing dependency, huh? Let’s take a quick search in http://mvnrepository.com/ and there it is, http://mvnrepository.com/artifact/org.apache.tapestry/plastic/5.3.5. I’m changing version in
build.gradleto ‘org.apache.tapestry:plastic:5.3.5’ and it worked: [gist id=”4df97a8cf51325afde4c”] So where do I find the sources? Well, it wasn’t hard to guess, it’s inside Tapestry source package, which actually isn’t that nice, because the promise was, it’s a separate project. Now that we have the source and some examples we can have some more fun… in the next part. One thing you can see already is that Howard L. Ship is using all the new, cool stuff to develop (Spock, Gradle), which makes it so much better experience to use the code, than it would be using old mainstream tools like Maven2 or JUnit.
RebasingFor me rebasing is merging 2.0. Assume you have a branch and some new code was introduced to master (or default or trunk, whatever). Now code tree looks like this (A, B, C, X, Y, Z are some commits) [sorry for those awful images of mine]:
More advanced exampleOk so let’s get back to real world. Let’s say we have some changes in branch feature1branch and we finished working on it. While waiting for code review to be done we want to start to work on feature2 in feature2branch, but we need some changes we made in first branch. So we build feature2branch on top of feature1branch. Here’s the graph: Code review is done, and we are free to check in to master. So we go to branch feature1branch and execute rebase master
CrashWhat would I expect to see is
and what we actually get is:
See the difference? Branch feature2branch now has it’s own copy of commits X, Y, Z and isn’t changed a bit! Rebasing only worked for the branch we specified. Pretty cool is you think about it, but misunderstanding this costed me some time couple of days ago.
- He showed that server cost per performance is underlinear (1 big computer costs less that two small) - I always believed the opposite
- He showed us the ease of vertical optimization as the future, not horizontal, as we see it.
Now when we add JRebel as javaagent to app it will start by reading this class and knows to check the directory (instead of dir we can watch jars and other stuff). Like in our example we would probably like to exclude some paths in directory not to scan the whole folder because it’s just too expensive. How to do that? Just add exclude/include tags in <dir/> tag. JRebel is a smart beast that can scan all the resources in classpath, including dependency jars. All we need to do is to put proper rebel.xml into each one of the (each we want to follow). Each has to say where JRebel can find new classes. I just lost about 2 hours because I called the file jrebel.xml instead of rebel.xml and wondered why doesn’t it scan path… :-/ Next thing to automate all of this is to add JRebel support to Maven build lifecycle, then we don’t need to create rebel.xml by had, and all of developers can use unified pom.xml (which will add project root path to rebel.xml). Remember to do this on all modules you want to have reloaded! Not just root or web project! Here’s how mine looks:
org.zeroturnaround jrebel-maven-plugin generate-rebel-xml process-resources generate