123 stories

Developers *still* prefer Java 8. What does this mean for Java 10 adoption?

1 Comment

We asked what Java version you're currently using and we received almost 300 answers. Now it's time to examine the results and see what this means for Java 10.

The post Developers *still* prefer Java 8. What does this mean for Java 10 adoption? appeared first on JAXenter.

Read the whole story
25 days ago
No surprise as Java 9 and Java 10 aren't LTS versions. The next Long Time Support will be Java 11. And there's not much value to adopt Java 9 or 10. I would rather migrate to Kotlin :)
Share this story

Spring Boot 2.0 is out: What’s new and noteworthy

1 Comment

After 17 months of hard work and over 6800 commits by 215 different individuals, Spring Boot 2.0 is finally here. Let's see what's new and noteworthy — and yes, Java 9 support is part of the deal.

The post Spring Boot 2.0 is out: What’s new and noteworthy appeared first on JAXenter.

Read the whole story
37 days ago
* Java 8 baseline, and Java 9 support
* Reactive web programming support with Spring WebFlux/WebFlux.fn
* Auto-configuration and starter POMs for reactive Spring Data Cassandra, MongoDB, Couchbase, and Redis.
* Reactive Spring
* Support for embedded Netty.
* HTTP/2 is now provided for Tomcat, Undertow, and Jetty
* Support for Kotlin 1.2.x
* Detects the jOOQ dialect automatically
* Auto-configures the open-source time series database InfluxDB
Share this story

What developers need to know about serverless technology

1 Comment

What does serverless technology bring to the table? In this article, Jignesh Solanki goes over some of the top tips developers need to know about this emerging tech solution.

The post What developers need to know about serverless technology appeared first on JAXenter.

Read the whole story
40 days ago
1. Serverless still includes servers

2. Microservices aren’t going to die

3. Focus on development cycle

4. Pay for what you actually use
Share this story

Owning the Role of the Front-End Developer

1 Comment

When I started working as a web developer in 2009, I spent most of my time crafting HTML/CSS layouts from design comps. My work was the final step of a linear process in which designers, clients, and other stakeholders made virtually all of the decisions.

Whether I was working for an agency or as a freelancer, there was no room for a developer’s input on client work other than when we were called to answer specific technical questions. Most of the time I would be asked to confirm whether it was possible to achieve a simple feature, such as adding a content slider or adapting an image loaded from a CMS.

In the ensuing years, as front-end development became increasingly challenging, developers’ skills began to evolve, leading to more frustration. Many organizations, including the ones I worked for, followed a traditional waterfall approach that kept us in the dark until the project was ready to be coded. Everything would fall into our laps, often behind schedule, with no room for us to add our two cents. Even though we were often highly esteemed by our teammates, there still wasn’t a chance for us to contribute to projects at the beginning of the process. Every time we shared an idea or flagged a problem, it was already too late.

Almost a decade later, we’ve come a long way as front-end developers. After years of putting in the hard work required to become better professionals and have a bigger impact on projects, many developers are now able to occupy a more fulfilling version of the role.

But there’s still work to be done: Unfortunately, some front-end developers with amazing skills are still limited to basic PSD-to-HTML work. Others find themselves in a better position within their team, but are still pushing for a more prominent role where their ideas can be fostered.

Although I’m proud to believe I’m part of the group that evolved with the role, I continue to fight for our seat at the table. I hope sharing my experience will help others fighting with me.

My road to earning a seat at the table

My role began to shift the day I watched an inspiring talk by Seth Godin, which helped me realize I had the power to start making changes to make my work more fulfilling. With his recommendation to demand responsibility whether you work for a boss or a client, Godin gave me the push I needed.

I wasn’t expecting to make any big leaps—just enough to feel like I was headed in the right direction.

Taking small steps within a small team

My first chance to test the waters was ideal. I had recently partnered with a small design studio and we were a team of five. Since I’d always been open about my soft spot for great design, it wasn’t hard to sell them on the idea of having me begin to get a bit more involved with the design process and start giving technical feedback before comps were presented to clients.

The results were surprisingly amazing and had a positive impact on everybody’s work. I started getting design hand-offs that I both approved of from a technical point of view and had a more personal connection with. For their part, the designers happily noticed that the websites we launched were more accurate representations of the comps they had handed off.

My next step was to get involved with every single project from day one. I started to tag along to initial client meetings, even before any contracts had been signed. I started flagging things that could turn the development phase into a nightmare; at the same time I was able to throw around some ideas about new technologies I’d been experimenting with.

After a few months, I started feeling that my skills were finally having an impact on my team’s projects. I was satisfied with my role within the team, but I knew it wouldn’t last forever. Eventually it was time for me to embark on a journey that would take me back to the classic role of the front-end developer, closer to the base of the waterfall.

Moving to the big stage

As my career started to take off, I found myself far away from that five-desk office where it had all started. I was now working with a much bigger team, and the challenges were quite different. At first I was amazed at how they were approaching the process: the whole team had a strong technical background, unlike any team I had ever worked with, which made collaboration very efficient. I had no complaints about the quality of the designs I was assigned to work with. In fact, during my first few months, I was constantly pushed out of my comfort zone, and my skills were challenged to the fullest.

After I started to feel more comfortable with my responsibilities, though, I soon found my next challenge: to help build a stronger connection between the design and development teams. Though we regularly collaborated to produce high-quality work, these teams didn’t always speak the same language. Luckily, the company was already making an effort to improve the conversation between creatives and developers, so I had all the support I needed.

As a development team, we had been shifting to modern JavaScript libraries that led us to work on our applications using a strictly component-based approach. But though we had slowly changed our mindset, we hadn’t changed the ways we collaborated with our creative colleagues. We had not properly shared our new vision; making that connection would become my new personal goal.

I was fascinated by Brad Frost’s “death to the waterfall” concept: the idea that UX, visual design, and development teams should work in parallel, allowing for a higher level of iteration during the project.

By pushing to progressively move toward a collaborative workflow, everyone on my team began to share more responsibilities and exchange more feedback throughout every project. Developers started to get involved in projects during the design phase, flagging any technical issues we could anticipate. Designers made sure they provided input and guidance after the projects started coming to life during development. Once we got the ball rolling, we quickly began seeing positive results and producing rewarding (and award-winning) work.

Even though it might sound like it was a smooth transition, it required a great amount of hard work and commitment from everybody on the team. Not only did we all want to produce better work but we also needed to be willing to take a big leap away from our comfort zones and our old processes.

How you can push for a seat at the table

In my experience, making real progress required a combination of sharpening my skills as a front-end developer and pushing the team to improve our processes.

What follows are more details about what worked for me—and could also work for you.

Making changes as a developer

Even though the real change in your role may depend on your organization, sometimes your individual actions can help jump-start the shift:

  • Speak up. In multidisciplinary teams, developers are known as highly analytical, critical, and logical, but not always the most communicative of the pack. I’ve seen many who quietly complain and claim to have better ideas on how things should be handled, but bottle up those thoughts and move on to a different job. After I started voicing my concerns, proposing new ideas, and seeing small changes within my team, I experienced an unexpected boost in my motivation and noticed others begin to see my role differently.
  • Always be aware of what the rest of the team is up to. One of the most common mistakes we tend to make is to focus only on our craft. To connect with our team and improve in our role, we need to understand our organization’s goals, our teammates’ skill sets, our customers, and basically every other aspect of our industry that we used to think wasn’t worth a developer’s time. Once I started having a better understanding of the design process, communication with my team started to improve. The same applied to designers who started learning more about the processes we use as front-end developers.
  • Keep core skills sharp. Today our responsibilities are broader and we’re constantly tasked with leading our teams into undiscovered technologies. As a front-end developer, it’s not uncommon to be required to research technologies like WebGL or VR, and introduce them to the rest of the team. We must stay current with the latest practices in our technical areas of focus. Our credibility is at stake every time our input is needed, so we must always strive to be the best developers in the business.

Rethinking practices within the company

In order to make the most of your role as a developer, you’ll have to persuade your organization to make key changes. This might be hard to achieve, since it tends to require taking all members of your team out of their comfort zones.

For me, what worked was long talks with my colleagues, including designers, management, and fellow developers. It’s hard for a manager to turn you down when you propose an idea to improve the quality of your work and only ask for small changes. Once the rest of the team is on board, you have to work hard and start implementing these changes to keep the ball rolling:

  • Involve developers in projects from the beginning. Many companies have high standards when it comes to hiring developers but don’t take full advantage of their talent. We tend to be logical thinkers, so it’s usually a good idea to involve developers in many aspects of the projects we work on. I often had to take the first step to be invited to project kickoffs. But once I started making an effort to provide valuable input, my team started automatically involving me and other developers during the creative phase of new projects.
  • Schedule team reviews. Problems frequently arise when teams present to clients without having looped in everyone working on the project. Once the client signs off on something, it can be risky to introduce new ideas, even if they add value. Developers, designers, and other key players must come together for team reviews before handing off any work. As a developer, sometimes you might need to raise your hand and invest some of your time to help your teammates review their work before they present it.
  • Get people to work together. Whenever possible, get people in the same room. We tend to rely on technology and push to communicate only by chat and email, but there is real value in face time. It’s always a good idea to have different teammates sit together, or at least in close enough proximity for regular in-person conversation, so they can share feedback more easily during projects. If your team works remotely, you have to look for alternatives to achieve the same effect. Occasional video chats and screen sharing can help teams share feedback and interact in real time.
  • Make time for education. Of all the teams I’ve worked on, those that foster a knowledge-sharing culture tend to work most efficiently. Simple and casual presentations among colleagues from different disciplines can be vital to creating a seamless variety of skills across the team. So it’s important to encourage members of the team to teach and learn from each other.

    When we made the decision to use only a component-based architecture, we prepared a simple presentation for the design team that gave them an overview of how we all would benefit from the change to our process. Shortly after, the team began delivering design comps that were aligned with our new approach.

It’s fair to say that the modern developer can’t simply hide behind a keyboard and expect the rest of the team to handle all of the important decisions that define our workflow. Our role requires us to go beyond code, share our ideas, and fight hard to improve the processes we’re involved in.

Read the whole story
48 days ago
Good tips for leveling up.
Share this story

Infix Functions in Kotlin

1 Comment

1. Introduction

Kotlin is a language that adds many fresh features to allow writing cleaner, easier-to-read code.

This, in turn, makes our code significantly easier to maintain and allows for a better end result from our development. Infix notation is one of such features.

2. What is an Infix Notation?

Kotlin allows some functions to be called without using the period and brackets. These are called infix methods, and their use can result in code that looks much more like a natural language.

This is most commonly seen in the inline Map definition:

  1 to "one",
  2 to "two",
  3 to "three"

“to” might look like a special keyword but in this example, this is a to() method leveraging the infix notation and returning a Pair<A, B>.

3. Common Standard Library Infix Functions

Apart from the to() function, used to create Pair<A, B> instances, there are some other functions that are defined as infix.

For example, the various numeric classes – Byte, Short, Int, and Long – all define the bitwise functions and(), or(), shl(), shr(), ushr(), and xor(), allowing some more readable expressions:

val color = 0x123456
val red = (color and 0xff0000) shr 16
val green = (color and 0x00ff00) shr 8
val blue = (color and 0x0000ff) shr 0

The Boolean class defines the and(), or() and xor() logical functions in a similar way:

if ((targetUser.isEnabled and !targetUser.isBlocked) or currentUser.admin) {
    // Do something if the current user is an Admin, or the target user is active

The String class also defines the match and zip functions as infix, allowing some simple-to-read code:

"Hello, World" matches "^Hello".toRegex()

There are some other examples that can be found throughout the standard library, but these are possibly the most common.

4. Writing Custom Infix Methods

Often, we’re going to want to write our own infix methods. These can be especially useful, for example, when writing a Domain Specific Language for our application, allowing the DSL code to be much more readable.

Several Kotlin libraries already use this to great effect.

For example, the mockito-kotlin library defines some infix functions — doAnswerdoReturn, and doThrow — for use when defining mock behavior.

Writing an infix function is a simple case of following three rules:

  1. The function is either defined on a class or is an extension method for a class
  2. The function takes exactly one parameter
  3. The function is defined using the infix keyword

As a simple example, let’s define a straightforward Assertion framework for use in tests. We’re going to allow expressions that read nicely from left to right using infix functions:

class Assertion<T>(private val target: T) {
    infix fun isEqualTo(other: T) {
        Assert.assertEquals(other, target)

    infix fun isDifferentFrom(other: T) {
        Assert.assertNotEquals(other, target)

This looks simple and doesn’t seem any different from any other Kotlin code. However, the presence of the infix keyword allows us to write code like this:

val result = Assertion(5)

result isEqualTo 5 // This passes
result isEqualTo 6 // This fails the assertion
result isDifferentFrom 5 // This also fails the assertion

Immediately, this is cleaner to read and easier to understand.

Note that infix functions can also be written as extension methods to existing classes. This can be powerful, as it allows us to augment existing classes from elsewhere — including the standard library — to fit our needs.

For example, let’s add a function to a String to pull out all of the substrings that match a given regex:

infix fun String.substringMatches(r: Regex) : List<String> {
    return r.findAll(this)
      .map { it.value }

val matches = "a bc def" substringMatches ".*? ".toRegex()
Assert.assertEquals(listOf("a ", "bc "), matches)

5. Summary

This quick tutorial shows some of the things that can be done with infix functions, including how to make use of some existing ones and how to create our own to make our code cleaner and easier to read.

As always, code snippets can be found over on over on GitHub.

Read the whole story
54 days ago
More of why Kotlin is so great :)
Share this story

Inspecting Docker container network traffic

1 Comment

When developing dockerized services with other communication end-points than browser client one soon needs some ways to capture and debug network traffic from containers. Here’s some tools and tips I’ve been using.

Capturing traffic

Docker uses network bridge for all traffic, and by default containers will be using bridge named docker0. However if you are using docker-compose, which by default creates own bridge for each configuration or you have other ways to configure docker networking the bridge you would like to capture would be different.

Use docker network ls command to list available Docker networks with the help of bridge link and ip addr show to find correct interface for your use case. Rest of this post will be using default docker0.

Docker Documentation for container networking has more details, and information for custom configurations.

Using tcpdump

Tcpdump is versatile commandline tool for capturing and analyzing network traffic. Try following to listen your containers:

tcpdump -i docker0

Or record traffic to a file:

tcpdump -i docker0 -w packets.cap

You could also use Wireshark which is GUI tool for analyzing traffic, and it could be also used to view output from tcpdump.

There’s still one problem though. Any sane service handling personal data should encrypt its communication preventing debuggin with simple packet capturing. To view encrypted TLS traffic we would need Man-in-the-middle transparently decryptin and re-encrypting traffic.

Setting up transparent HTTP(S) proxy

For man-in-the-middle setup we need following:

  1. Proxy
  2. IP packet forwarding to redirect traffic to proxy
  3. Configure CA certificates from proxy as trusted by the service we are examining

Mitmproxy is a perfect tool for this job.

Packet forwarding and Mitmproxy setup

  1. See Mitmproxy documentation for installation options or run it using official Docker images
  2. Enable packet forwarding in your host system with sysctl:

    sysctl -w net.ipv4.ip_forward=1
  3. Use iptables to forward interesting traffic from bridge to proxy. Following will forward HTTP targeting default port 80 and HTTPS to default port 443 to proxy running in 8080 which is Mitmproxy default.

    iptables -t nat -A PREROUTING -i docker0 -p tcp --dport 80 -j REDIRECT --to-port 8080
    iptables -t nat -A PREROUTING -i docker0 -p tcp --dport 443 -j REDIRECT --to-port 8080
  4. Run mitmproxy in transparent mode:

   mitmproxy -T --host

Configure CA certificates

Now HTTPS clients configured to verify server certificates would fail connecting, which will look like following in then Mitmproxy event log:

Mitmproxy event log

Mitmproxy generates its CA to directory $HOME/.mitmproxy, which could be mounted as a volume to your Docker container. If your are using Docker to run Mitmproxy you would mount volumes from that container.

docker run --volume $HOME/.mitmproxy:/usr/share/ca-certificates/custom some-image

Rest depends on used Linux distribution and service implementation you are targeting:

  • For Unix system tools in Alpine Linux based containers:

    1. Mount custom certificates under some dir eg. custom at /usr/share/ca-certificates

      docker run -v ~/.mitmproxy:/usr/share/ca-certificates/custom ...
    2. Add custom/mitmproxy-ca-cert.pem to /etc/ca-certificates.conf in your container

      echo custom/mitmproxy-ca-cert.pem >> /etc/ca-certificates.conf
    3. Update trusted root certificates by running:

  • NodeJS has support for NODE_EXTRA_CA_CERTS environment variable since v7.3.0

  docker run --volume $HOME/.mitmproxy:/opt/extra-ca -e NODE_EXTRA_CA_CERTS=/opt/extra-ca/mitmproxy-ca-cert.pem nodejs
  • Ruby OpenSSL uses system root certs or they could be overriden with SSL_CERT_FILE and SSL_CERT_DIR environment variables
  • For example Go, Elixir, Python based implementations would use system root certificates

After these steps it is possible to examine TLS traffic.

Mitmproxy showing response headers from TLS encrypted communication

Extra tricks with mitmproxy

Possibilities with Mitmproxy are not limited to just inspection. For example see official documentation for how to edit request or response before letting it go through proxy to client or server.

Read the whole story
87 days ago
Good tips for capturing and debugging network traffic from Docker containers.
Share this story
Next Page of Stories