BSiDeUp's blog

How to use QueryDSL with JPA, Gradle and IDEA

2015-04-30T21:59:00.000+03:00

QueryDSL is cool Database Query DSL for Java. I will recommend you to check it if you still don't know what is it. But there are not so much information on how to use it with Gradle. Also, it's not so clear about Intellij IDEA integration. With this article I would like to point you on querydsl-apt and Java annotations processors discovery.

Similar to projects like Lombok since version 2.7.1 QueryDSL has support for Java annotation processors discovery: https://github.com/querydsl/querydsl/issues/180. It means that we don't have to configure code generation manually, javac will pick up annotation processor automagically.

Gradle

Gradle setup is really easy. You can start with example project created by me: https://github.com/bsideup/querydsl-gradle-idea/tree/10ffd70805e3a7951d4614ff4f7e27102fdad343

build.gradle is simple:

We're declaring dependency on querydsl-apt:3.6.3 with jpa classifier. It contains Java Annotation Processor for JPA annotations like @Entity. If you already have a project with QueryDSL and just want to improve your Gradle build - just remove everything related to QueryDSL code generation and just add this dependency.

Now you can build your project:

$ ./gradlew build
:compileJava
Note: Running JPAAnnotationProcessor
Note: Serializing Entity types
Note: Generating ru.trylogic.querydsl.example.QUser for [ru.trylogic.querydsl.example.User]
Note: Running JPAAnnotationProcessor
Note: Running JPAAnnotationProcessor
:processResources
:classes
:jar
:assemble
:compileTestJava UP-TO-DATE
:processTestResources UP-TO-DATE
:testClasses UP-TO-DATE
:test UP-TO-DATE
:check UP-TO-DATE
:build

BUILD SUCCESSFUL

Total time: 2.768 secs

There are notes about annotation processing from JPAAnnotationProcessor. It means that everything works as expected and code was generated. Easy, huh?

IntelliJ IDEA

But we don't want to build our project with Gradle during development, we want to use build from IDEA! First, change your build.gradle file:

Now open project in IDEA (if you didn't import project yet you can easily open build.gradle file in IDEA, it will propose you to import it). For some reasons IDEA will not enable annotation processing by default when you import your Gradle project, so you need to enable it.

Go to Preferences -> Build, Execution, Deployment -> Annotation Processors;
Check Enable annotation processing checkbox;
In "Store generated sources relative to:" select Module content root.

Now if you will build your project, QueryDSL will generate code for your entities and you will be able to use it like this:

As always, full sources can be found here: http://github.com/bsideup/querydsl-gradle-idea/

Spring Boot's fat jars vs. Docker

2015-04-12T13:56:00.000+03:00

I love Spring Boot. I really do. But I'm also do love Docker. And combination of them makes me really happy ~~panda~~ developer. But one of the most coolest things about Spring Boot - fat jars - anti-pattern in Docker world, where images should be layered. Can we solve this? Heck yeah!

Preparations

First we need to create Spring Boot project for tests. I will use Spring Boot CLI and single-Groovy-file project for this. Let's "clone" application from this tweet:

Now if you will run

spring jar app.jar app.groovy

You will get fat app.jar with your entire project. What is the size for this jar? 17Mb. Why? Because it's fat and contains whole Spring Boot stack, including Spring Framework, Groovy and even embedded Tomcat! Now we can pack it with Docker:

What's wrong with it? Let's build an image:

$ docker build .
Sending build context to Docker daemon 34.87 MB
Sending build context to Docker daemon
Step 0 : FROM java:8-jre
 ---> 028f36974b77
Step 1 : ADD app.jar /app/
 ---> f39fac8b6c8d
Removing intermediate container d3c168bb5b09
Step 2 : CMD java -jar /app/app.jar
 ---> Running in 3fbb5ba0cf4b
 ---> 51d0def78e12
Removing intermediate container 3fbb5ba0cf4b
Successfully built 51d0def78e12

Now change message inside your app.groovy file to "Hello dockerized world!" and pack it again with "spring jar" command above. If you will build your Docker image one more time than it will create a new layer the same size - 17Mb. And every time you need to change something in your project you will create a layer with all dependencies.

Exploded Jar? WAT?

Did you know that you can explode your fat jar and still can run it? Just try yourself, it works with any Spring Boot-based fat jar:

$ unzip -q app.jar -d app
$ java -cp app org.springframework.boot.loader.JarLauncher --server.port=8081
  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::        (v1.2.3.RELEASE)


...

2015-04-12 13:22:44.484  INFO 6379 --- [           main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8081 (http)
2015-04-12 13:22:44.486  INFO 6379 --- [           main] .b.c.j.PackagedSpringApplicationLauncher : Started PackagedSpringApplicationLauncher in 2.706 seconds (JVM running for 3.078)

How it can help us? Answer is inside an exploded directory:

$ ls -la app
total 24
drwxr-xr-x   7 bsideup  staff   238 Apr 12 13:21 .
drwxr-xr-x   6 bsideup  staff   204 Apr 12 13:21 ..
-rw-r--r--   1 bsideup  staff    75 Apr 12 12:38 Dockerfile
drwxr-xr-x   3 bsideup  staff   102 Apr 12 12:38 META-INF
-rw-r--r--   1 bsideup  staff  5136 Apr 12 12:38 ThisWillActuallyRun.class
drwxr-xr-x  37 bsideup  staff  1258 Apr 12 12:38 lib
drwxr-xr-x   3 bsideup  staff   102 Apr 12 12:38 org

Do you see this "lib" folder? It contains all your project dependencies. They are not changing often. So why not to cache them?

Docker caching

How to cache something in Docker? Just "ADD" it before the main files. Modify your Dockerfile with this changes:

And build your image:

$ rm -rf app/ && unzip -q app.jar -d app
$ docker build .
Sending build context to Docker daemon 34.87 MB
Sending build context to Docker daemon
Step 0 : FROM java:8-jre
 ---> 028f36974b77
Step 1 : ADD app/lib/ /app/lib/
 ---> 01fd4225441d
Removing intermediate container 77d555817fa8
Step 2 : ADD app /app/
 ---> 846a92bd6fc3
Removing intermediate container 86b26a48efde
Step 3 : CMD java -cp /app/ org.springframework.boot.loader.JarLauncher
 ---> Running in 2e677531c0e5
 ---> e90f469994c7
Removing intermediate container 2e677531c0e5
Step 4 : EXPOSE 8080
 ---> Running in f05d3868f6ed
 ---> 526ff5ad98ae
Removing intermediate container f05d3868f6ed
Successfully built 526ff5ad98ae

Now on Step 1 Docker will create a layer with your libraries and cache it until they will be changed.

Not so fast

UPDATE: since this fix https://github.com/spring-projects/spring-boot/issues/2807 future steps are not required anymore if you're using Spring Boot 1.3.0 or newer.

What will happen if you will run "spring jar" command again and then build an image? Depends on your Docker knowledge. Lets try:

$ spring jar app.jar app.groovy
$ rm -rf app/ && unzip -q app.jar -d app
$ docker build .
Sending build context to Docker daemon 34.87 MB
Sending build context to Docker daemon
Step 0 : FROM java:8-jre
 ---> 028f36974b77
Step 1 : ADD app/lib/ /app/lib/
 ---> 3270477dd01f
Removing intermediate container 08a0ab7ed4ef
Step 2 : ADD app /app/
 ---> f9372f874d47
Removing intermediate container 751de4852196
Step 3 : CMD java -cp /app/ org.springframework.boot.loader.JarLauncher
 ---> Running in 4954fb8d37d3
 ---> e2fc978f2740
Removing intermediate container 4954fb8d37d3
Step 4 : EXPOSE 8080
 ---> Running in 9f70e24d5bc0
 ---> 75999f39321b
Removing intermediate container 9f70e24d5bc0
Successfully built 75999f39321b

This was my first reaction on happened. But then I realized that timestamp for libraries was changed after packaging. Can we fix it? Yes we can!

$ find ./app/lib/ | xargs touch -t 0000000000.00
$ docker build .
Sending build context to Docker daemon 34.87 MB
Sending build context to Docker daemon
Step 0 : FROM java:8-jre
 ---> 028f36974b77
Step 1 : ADD app/lib/ /app/lib/
 ---> 8028a9ba2b7b
Removing intermediate container 52d21772824a
Step 2 : ADD app /app/
 ---> 7ed806b0089f
Removing intermediate container f070b31695bf
Step 3 : CMD java -cp /app/ org.springframework.boot.loader.JarLauncher
 ---> Running in 9a84ec5214ae
 ---> 8fda50a60f87
Removing intermediate container 9a84ec5214ae
Step 4 : EXPOSE 8080
 ---> Running in 8543d0799c68
 ---> 06614c96e115
Removing intermediate container 8543d0799c68
Successfully built 06614c96e115

Now every new build will use cache for libraries:

$ spring jar app.jar app.groovy
$ rm -rf app/ && unzip -q app.jar -d app
$ find ./app/lib/ | xargs touch -t 0000000000.00
$ docker build .
Sending build context to Docker daemon 34.87 MB
Sending build context to Docker daemon
Step 0 : FROM java:8-jre
 ---> 028f36974b77
Step 1 : ADD app/lib/ /app/lib/
 ---> Using cache
 ---> 8028a9ba2b7b
Step 2 : ADD app /app/
 ---> e0b404447dbe
Removing intermediate container 8952413133a9
Step 3 : CMD java -cp /app/ org.springframework.boot.loader.JarLauncher
 ---> Running in 8c2e55128dc0
 ---> 30f8fb7f4eba
Removing intermediate container 8c2e55128dc0
Step 4 : EXPOSE 8080
 ---> Running in b08967c7a454
 ---> 9e028bbfef90
Removing intermediate container b08967c7a454
Successfully built 9e028bbfef90

Now your services are real microservices.

Building Microservices with Spring Boot and Apache Thrift. Part 3. Asynchronous services

2015-04-08T16:12:00.004+03:00

Have you thought about making your server asynchronous? How much time your server spent in database calls? External service calls? New shiny database library now supports asynchronous queries? It's time to processing requests in an async manner! And it's super easy with Facebook Swift!

Hardest part

How do you think, how much changes you need to do to make your Swift service asynchronous? Do you afraid of it? You already scheduled a week for this refactoring? Oh, that's nice:)

Now it's time to update your service implementation. Are you ready?

Hope you noticed this ScheduledExecutorService and 2 seconds delay. You shouldn't use it in your real application, this is just for example of promises (unless you want to simulate work for future optimizations like this guy: http://thedailywtf.com/articles/The-Speedup-Loop )

That's it, now your server is asynchronous. There is more - your clients can consume your service like before in non-async manner. How cool is that?

Full source code at GitHub: https://github.com/bsideup/spring-boot-swift/tree/async

Previous parts:

Building Microservices with Spring Boot and Apache Thrift. Part 2. Swifty services

2015-04-07T14:14:00.001+03:00

In previous article I showed you how to use pure Apache Thrift to create protocols for your services. This time I will explain how to use Facebook Swift (not the best name for project BTW :)) to get rid of Thrift IDL files for server code.

Few words about Swift. Swift - Java annotation-based generator for Apache Thrift. It's priceless when you develop your APIs in Java and want to expose them to the other world using Apache Thrift.

Protocol

Lets recreate our previous example ( https://github.com/bsideup/spring-boot-thrift ) with it. Start with simple build.gradle file:

Nothing special, Spring Boot with few Facebook Swift libraries.

Next we need to add Swift protocol classes:

Exception is simple Swift struct which extend Exception (See Ma no TException)

Enums are handled with Swift, so we don't need to annotate them (but we can)

Next - application main class for Spring Boot:

Test

Now we're ready to write some tests:

As you can see, only difference here (compared to Thrift version) is setUp method.
Diff with Thrift version

Implementation

We still have no Swift service implementation. Implementation of handler looks almost the same as previous:

Diff with Thrift version

Now if you will run tests you should see all tests green.

Thrift integration

But hey, how about other non-Java consumers of service? Don't worry, Swift comes with a tool for generating *.thrift files from annotated Java classes: https://github.com/facebook/swift/tree/master/swift2thrift-generator-cli

Example output for our service will be:

Conclusion

Full source files for this example can be found at GitHub: https://github.com/bsideup/spring-boot-swift

Next time I will show you how to write Async Thrift services using Swift with minimal changes. Stay tuned!

Как получить .hex из Arduino?

2010-08-16T23:09:00.000+03:00

начиная с версии 0018, в Arduino IDE нет возможности сохранять .hex файл в папку с скетчем. Но не стоит отчаиваться - выход естественно есть)

Запускаем нашу Arduino IDE, и открываем наш "любимый" скетч, нажимаем Verify:

Дальше, открываем проводник и пишем там %temp%\ и нажимаем Enter:

Находим там папки с именами buildXXXXXXXXXXXXXXX.tmp:

В каждой из этих папок будет куча файлов, нас интересует файл Blink.cpp.hex - это и есть наш скомпилированный Blink, который можно заливать на микросхему (или, скормить Proteus-у ))))

Примечание
Когда вы производите изменения с исходным текстом скетча, то папка buildXXXXXXXXX.tmp очищается автоматически, и вам надо заного нажать Verify, чтобы в ней появились файлы. На самом деле, даже удобно, если сделали изменения, но не сохранили - протеус, к примеру, начинает сразу кричать вопить, мол, файла то нету, куда файл дели)

Arduino на atmega48 и atmega88

2010-08-16T22:55:00.003+03:00

Начну цикл статей с пособия, как программировать на Arduino-платформе, но в качестве микроконтроллера использовать atmega48 (да-да, это возможно). Основывается это на том факте, что различия atmega48 от atmega328 только лишь в количестве ОЗУ и ПЗУ

На самом деле, это очень просто.

Порядок действий:

1) откройте файл arduino-0018/hardware/arduino/boards.txt и добавьте в его конец что-то вроде этого:

######################################################

atmega48.name=ATMega48

atmega48.upload.using=avrisp

atmega48.upload.maximum_size=4094

atmega48.upload.speed=38400

atmega48.bootloader.low_fuses=0xE2

atmega48.bootloader.high_fuses=0xDF

atmega48.bootloader.extended_fuses=0xFF

atmega48.bootloader.path=atmega

atmega48.bootloader.file=atmega48.hex

atmega48.bootloader.unlock_bits=0x3F

atmega48.bootloader.lock_bits=0x0F

atmega48.build.mcu=atmega48

atmega48.build.f_cpu=8000000L

atmega48.build.core=arduino

2) Подсоедините AVCC микроконтроллера к плюсу питания (используется для analogRead как analog reference)

3) Поставьте конденсатор примерно в 0,1мкФ между AREF и землёй

4) enjoy!

А теперь о плохом %)

доступно тока 4кб памяти, что накладывает сильные ограничения на размер скетча (при использовании bootloader-а - всего 2кб), так что, скорей всего, грузить скетчи на плату вам придёться с помощью программатора (либо, имея под рукой другую arduino, можно прошить микроконтроллер с помощью ICSP, благо, в интернете более чем достаточно статей об этом)

Как получить .hex файл из скетча для заливки на МК, я описал в отдельной статье:
http://bsideup.blogspot.com/2010/08/hex-arduino.html