Ketan's Home

April 29, 2018

Spring Tips: Spring Statemachine [Video]

Filed under: Uncategorized — ketan @ 10:08 PM

Get the Edge with a Professional Java IDE.

30-day free trial


Get the Java IDE

that understands code & makes developing enjoyable. Level up your code with IntelliJ IDEA.

Download the free trial



spring statemachine
process state

from Javalobby

April 23, 2018

Three Common Mistakes of the First Time Tech Lead

Filed under: Uncategorized — ketan @ 11:29 PM

The first time a developer steps into the role of a Tech Lead can be difficult. The skills and experience of a seasoned developer do not automatically translate into the skills necessary for the Tech Lead role. In fact, some of the habits of a developer can do more harm than good, when not applied well and with more authority in this new role.

3 mistakes

In this article, we explore three common traps a first time Tech Lead experiences, and what they can do to avoid them.

1. Coding Full-Time

A first time Tech Lead will miss writing code. In fact, it is easy for them to assume that they need to demonstrate their leadership by writing code all the time. Although effective Tech Leads need to spend some time writing, reading and reviewing code, other responsibilities are left unfulfilled when they spend too much time writing code, – such as creating a technical vision and ensuring that the team understands key system quality attributes.

A lack of technical vision might lead to three different implementations, as developers make decisions individually about what they feel is best, or a deployment might fail because developers are not aware of operational constraints or environmental differences in production. Worse yet is when the code must constantly be reworked because a developer chooses to do something differently without considering maintenance, or how the system may evolve over time.

The more experienced Tech Lead understands that they must balance their time to code with other responsibilities. They split their time daily, or at the very least weekly, to ensure that they spend time addressing other responsibilities including building a shared architectural vision, identifying and addressing technical risks, being involved in planning sessions and focusing on team and code cohesiveness and consistency.

2. Making all the Technical Decisions

A first time Tech Lead may sometimes be the most experienced developer on the team, or feel the pressure to make all the technical decisions to demonstrate their authority or influence. When a Tech Lead is making all the technical decisions, they become a bottleneck in the team and the team cannot progress when the Tech Lead is not around. Other team members might feel demotivated when the Tech Lead makes all the important decisions, because their contributions are overruled and this could lead to resentment.

The more experienced Tech Lead realizes there are different ways of making decisions, and often, the best decision comes from using the breadth of experience and knowledge from the entire team. They might draw upon the following techniques, depending on how critical a decision is, how quick a decision must be made and how much commitment they want from team members:

  • Only delegating – A Tech Lead gives the decision to someone else without any other interaction
  • Offering advice – A Tech Lead delegates the decision to someone else, but offers their input and opinions for consideration
  • Inquiring – A Tech Lead delegates the decision to someone else, but inquires about the outcome and factors that led to the decision afterwards
  • Building consensus – They bring all team members together to find a solution that everyone is happy with
  • Consulting with the team – They invite opinions from team members, synthesise the information, but ultimately make the final decision
  • Being autocratic – They use the information they have to make a decision, choosing to involve or not involve team members, but inform everyone about the outcome.

3. Forgetting about Cultivating Team Culture

A team is a group of people working together towards the same goal. The first time Tech Lead might mistakenly see their role leading on all the technical aspects and forget about how the team works together. Although this responsibility may be shared with other roles such as the Team Lead or Project Manager, a Tech Lead must also shepherd the team to move in the same technical direction.

It is all too easy for the first time Tech Lead to ignore heated discussions between two developers, or to ignore how technical team members interact poorly with or disrespect non-technical team members.

The more experienced Tech Lead realizes that the lead part of their role is just as important as the tech, and constantly looks for ways to build trust and relationships between people in the team. They use practices like white-boarding architectural diagrams as a team, establishing coding or architectural principles with the team to guide individual decisions or running regular improvement katas or retrospectives.


The first time Tech Lead can easily fall for a number of traps, often caused by habits developed from their time as a developer. To overcome these traps, they must find ways to strike a balance between their technical and leadership responsibilities.

from Java Code Geeks

April 22, 2018

Fix Your Insecure Amazon Fire TV Stick

Filed under: Uncategorized — ketan @ 10:08 PM

I recently spent a largely sleepless night at a hotel, and out of equal parts curiosity and boredom, decided to kill some time scanning the guest network to see what my fellow travelers might be up to. As you’d probably expect, I saw a veritable sea of Samsung and Apple devices. But buried among the seemingly endless number of smartphones charging next to their sleeping owners, I found something rather interesting. I was as picking up a number of Amazon-made devices, all of which had port 5555 open.

As a habitual Android tinkerer, this struck me as very odd. Port 5555 is used for Android Debug Bridge (ADB), a development tool used to control and perform various administrative tasks on an Android device over the network or (more commonly) locally over USB. The number of users who would have legitimately needed to enable network ADB on their devices is surely rather low, so to see a half dozen of them on the network at the same time seemed improbable to say the least.

Why would so many devices manufactured by Amazon all have network ADB enabled? I realized there must be a connection, and it didn’t take long to figure it out.

The Seedy World of “Jailbroken” Fire Sticks

The somewhat awkwardly named “Fire TV Stick” is a cheap little device that you stick in the HDMI port of your TV to turn it into a “smart” TV. Ostensibly it allows you to stream content from all the big name providers out there, but realistically Amazon is hoping it will get you to spend more money within their ecosystem. For Amazon, the Fire Stick is to video content as the Kindle is to books: sell the hardware cheap, and make money on the subsequent content purchases.

Millions of Fire Stick owners have made the switch

That was the plan, anyway. But it didn’t take long for people to realize that the Fire Stick was running Amazon’s customized version of Android, and what’s more, was particularly easy to install additional software onto. As you might expect, a huge community of Fire Stick modifications and hacks sprung up in some of the less fashionable parts of the Internet, largely focused on turning the Fire Stick into the ultimate device for illicit video content.

How do you install this software, you might ask? It’s simple, and about a thousand different guides and YouTube videos will walk you through the process of “jailbreaking” your Fire Stick. All you need to do is go into “Developer Options” and enable “Apps from Unknown Sources” and “ADB Debugging”. Theses handy-dandy guides don’t bother to explain the dangers of doing this, nor do they caution the user to turn off these settings after they’ve installed the third party software of choice (usually Kodi).

The end result is a whole community of people using Amazon Fire TV Sticks in development mode, where anyone can connect to these devices over the network and gain full control over them. A potential botnet, created by willing participants.

Realistic Risk

To be fair, most of these Fire Sticks will never leave the user’s some. In such a situation, while there’s still no good reason to allow remote ADB on these devices, the risk is probably low enough that there’s no great danger to leaving it on. But if you’re using a “jailbroken” Fire Stick on a public network, such as a school dorm or hotel, you’re asking for trouble.

It should be said that the Fire Stick does pop up a message when a device tries to connect over remote ADB. But it’s not a terribly descriptive message, and certainly doesn’t tell the user what this big complicated string of characters means. It doesn’t even say that the connection is coming from a remote device. To add insult to injury, “OK” is the default action when the prompt comes up.

Frankly, it’s a pretty terrible “warning” message for the average user. Granted this message was never intended to show up during normal operation of the Fire Stick (remember, you must first enable “Developer Options” to get to this point), but still. The majority of people will simply press the “OK” button as fast as possible to get this scary Matrix-code off of their TVs so they can get back to watching Netflix.

Once the user hits “OK”, it’s game over. With ADB access approved, an attacker would be free to install and execute their own software, wipe the Fire Stick, or do basically anything else they wanted.

Sniffing for Fire Sticks

If you want to go on the hunt for ADB enabled Fire Sticks, the first thing you need to do is identify Amazon-manufactured devices on the network. There are many ways you could do this, but a quick one-line from a *nix machine with arp-scan installed would look something like: sudo arp-scan --localnet | grep Amazon. This would find the MAC addresses for all the devices on the local network, then pipe that to grep which would search the results for the word “Amazon”.

If it’s on the LAN and was made by Amazon, that should get you it’s IP address. The next step would be port scanning each of those IPs. Again there are plenty of ways to do this on different platforms, but nmap is always a good bet. Of course, if it’s only one or two devices you could always just try connecting to them directly with adb connect and seeing what happens.

While tinkering with this concept I’ve come up with a Python script which scans the local network for potentially vulnerable Amazon devices. This script could easily be expanded to actively connect to those devices and execute commands on them (such as rebooting the device), but for obvious reasons I’ll let that be an exercise for the reader.

The Takeaway

This is a perfect example of why you need to be exceptionally cautious when following guides posted online. Whether it’s due to ignorance or indifference, the individuals who create these clickbait “jailbreaking” guides for the Amazon Fire Stick don’t adequately explain the risks of enabling “Developer Options”, and the Fire Stick itself doesn’t do much better in terms of warning the average consumer about allowing remote devices to connect.

It’s also important to remember how sophisticated these “simple” media player devices are becoming. In the case of the Fire Stick, we’re talking about a full fledged computer running Android, and all that entails. It’s not outside the realm of possibility that your Fire Stick could be compromised with a Trojan horse style application, and then become a backdoor into your home network. What seemed like a cheap way to watch streaming movies could end up costing more than you bargained for.

TL;DR: Turn off remote debugging.

from Hack a Day

Home Made 5-Axis CNC Head Is A Project To Watch

Filed under: Uncategorized — ketan @ 9:54 PM

Home Made 5-Axis CNC Head Is A Project To Watch

[Reiner Schmidt] was tired of renting an expensive 5-axis CNC head for projects, so he decided to build his own. It’s still a work in progress, but he’s made remarkable progress so far. The project is called Bridge Boy, and it is designed to use a cheap DC rotary mill to cut soft materials like plastic, wood and the like. Most of it is 3D printed, and he has released the Autodesk 360 plans that would allow you to start building your own. His initial version uses an Arduino with stepper drivers, and is designed to fit onto the end of a 60mm arm of a standard 3-axis CNC,  so technically it’s a 3+2 axis CNC. With the appropriate software, it should be able to work as a full 5-axis machine, though, and it should be possible to integrate it with a CNC that has a 5-axis driver board without too much effort.

This is definitely a project to watch, as his work so far is very nicely designed and doesn’t look like it would be too difficult to print and build once the design is a bit further along.

[Via Reddit]

from Hack a Day

April 7, 2018

Mini book: The JHipster Mini-Book 4.5

Filed under: Uncategorized — ketan @ 1:51 PM

The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster. JHipster is a Yeoman generator that can be used to a create a project and generate boilerplate code for you. This book shows you how to build an app with JHipster.

By Matt Raible

from InfoQ

Blog at