Ketan's Home

November 29, 2018

Scratch-Building A Supersized Laser Cutter

Filed under: Uncategorized — ketan @ 6:31 PM

Now that 3D printers have more or less hit the mass market, hackers need a new “elite” tool to spend their time designing and fiddling with. Judging by the last couple of years, it looks like laser cutters will be taking over as the hacker tool du jour; as we’re starting to see more and more custom builds and modifications of entry-level commercial models. Usually these are limited to relatively small and low powered diode lasers, but as the following project shows, that’s not always the case.

This large format laser cutter designed and built by [Rob Chesney] is meticulously detailed on his blog, as well as in the in the video after the break. It’s made up of aluminium profile and a splattering of ABS 3D printed parts, and lives in an acrylic enclosure that’s uniquely isolated from the laser’s internal gantry. All told it cost about $2,000 USD to build, but considering the volume and features of this cutter that’s still a very fair price.

[Rob] carefully planned every aspect of this build, modeling the entire machine in CAD before actually purchasing any hardware. Interestingly enough his primary design constraint was the door to his shed: he wanted to build the largest possible laser cutter that could still be carried through it. That led to the final machine’s long and relatively shallow final dimensions. The design was also guided by a desire to minimize material waste, so when possible parts were designed to maximize how many could be cut from a one meter length of aluminum extrusion.

The laser features a movable Z axis that’s similar in design to what you might see in a Prusa-style 3D printer, with each corner of the gantry getting an 8 mm lead screw and smooth rod which are used in conjunction to lift and guide. All of the lead screws are connected to each other via pulleys and standard GT2 belt, but as of this version, [Rob] notes the Z axis must be manually operated. In the future he’ll be able to add in a stepper motor and automate it easily, but it wasn’t critical to get the machine running.

He used 3D printed parts for objects which had a relatively complex geometry, such as the laser tube holders and Z axis components, but more simplistic brackets were made out of cut acrylic. In some components, [Rob] used welding cement to bond two pieces of acrylic and thereby double the thickness. Large acrylic panels were also used for the laser’s outer enclosure, which was intentionally designed as a separate entity from the laser itself. He reasoned that this would make assembly easier and faster, as the enclosure would not have to be held to the same dimensional tolerances as it would have been if it was integrated into the machine.

[Rob] gives plenty of detail about all the finer points of water cooling, laser control electronics, aligning the mirrors, and really anything else you could possibly want to know about building your own serious laser cutter. If you’ve been considering building your own laser and have anything you’re curious or unsure about, there’s a good chance he addresses it in this build.

Short of having the fantastically good luck to find a laser cutter in the trash that you can refurbish, building your own machine may still be the best upgrade path if you outgrow your eBay K40.

from Hack a Day https://ift.tt/2QVXOsA

November 16, 2018

Smooth Moves from Cheap Motors

Filed under: Uncategorized — ketan @ 8:09 AM

Smooth Moves from Cheap Motors

Building an electric motor isn’t hard or technically challenging, but these motors have very little in the way of control. A stepper motor is usually employed in applications that need precision, but adding this feature to a motor adds complexity and therefore cost. There is a small $3 stepper motor available, but the downside to this motor is that it’s not exactly the Cadillac of motors, nor was it intended to be. With some coaxing, though, [T-Kuhn] was able to get a lot out of this small, cheap motor.

To test out the motors, [T-Kuhn] built a small robotic arm. He began by programming his own pulse generating algorithm that mimics a sine wave in order to smooth out the movement of the motor. An Arduino isn’t fast enough to do these computations, though, so he upgraded to using the ESP32. He also was able to implement the inverse kinematics on his own. The result of all this work for a specific platform and motor type is a robotic arm that has a very low cost but delivers performance of much more expensive hardware.

The robot arm was built by [T-Kuhn] too, and all of the details on that build, as well as all the schematics and code, are available on the project site if you need a low-cost robot arm or a good stepper motor controller for a low cost. There are many other ways of getting the most out of other types of low-cost motors as well.

from Hack a Day https://ift.tt/2K7SXSw

November 11, 2018

Lightsaber Uses Pogo Pins to Make Assembly a Breeze

Filed under: Uncategorized — ketan @ 12:03 PM

There was an endless supply of fantastic projects at Supercon this year, but one whose fit and finish really stood out was [Scott]’s lightsaber. If you were walking around and saw someone with a very bright RGB device with a chromed-out handle hanging off their belt it was probably this, though it may have been hard to look at directly. On the outside, the saber looks like a well-polished cosplay prop, and it is! But when Scott quickly broke down the device into component pieces it was apparent that extra care had been put into the assembly of the electronics.

Like any good lightsaber replica the blade is lit, and wow is it bright. The construction is fairly simple, it’s a triplet of WS2812B LED strips back to back on a triangular core, mounted inside a translucent polycarbonate tube with a diffuser. Not especially unusual. But the blade can be popped off the hilt at a moments notice for easy transport and storage, so the strips can’t be soldered in. Connectors would have worked, but who wants flying wires when they’re disconnecting their lightsaber blade. The answer? Pogo pins! Scott runs the power, ground, and data lines out of the strips and into a small board with slip ring-style plated rings. On the hilt, there is a matching array of pogo pins to pass along power and data. The data lines from all the strips are tied together minimizing the number of connections to make, and the outer two power rings have more than one pin for better current-carrying capacity. A handy side effect is that there is nowhere on the blade where there aren’t LEDs; the strips go down to the very end of the blade where it meets the main board inside the hilt.

The hilt is filled with an assembly of 18650’s and a Teensy mounted with a custom shield, all fit inside a printed midframe. The whole build is all about robust design that’s easy to assemble. The main board is book-ended by perpendicular PCBs mounted to the ends, one at the top to connect to the blade and one at the bottom to connect to a speaker. Towards the bottom there is space for an optional Bluetooth radio to allow remote RGB control.

Scott is selling this as a product but also provides detailed instructions and parts lists for each component. Assembly instructions for the blade are here. The hilt is here. And pogo adapters are on OSH Park here. An overview of the firmware with links to GitHub is here. Check out a walkthrough of the handle assembly and blade attachment after the break!

from Hack a Day https://ift.tt/2D86kR6

Arduino Gets a Command Line Interface

Filed under: Uncategorized — ketan @ 10:29 AM

Arduino Gets a Command Line Interface

When using an Arduino, at least once you’ve made it past blinking LEDs, you might start making use of the serial connection to send and receive information from the microcontroller. Communicating with the board while it’s interacting with its environment is a crucial way to get information in real-time. Usually, that’s as far as it goes, but [Pieter] wanted to take it a step farther than that with his command line interpreter (CLI) for the Arduino.

The CLI allows the user to run Unix-like commands directly on the Arduino. This means control of GPIO and the rest of the features of the microcontroller via command line. The CLI communicates between the microcontroller and the ANSI/VT100 terminal emulator of your choosing on your computer, enabling a wealth of new methods of interacting with an Arduino.

The CLI requires a hex file to be loaded onto the Arduino that you can find at a separate site, also maintained by [Pieter]. Once that’s running, you can get all of that sweet command line goodness out of your Arduino. [Pieter] also has some examples on his project page, as well as the complete how-to to get this all set up and running. There’s a lot going on in the command line world, in Linux as well as windows. So there’s plenty to explore there as well.

from Hack a Day https://ift.tt/2qFbLjl

Design Patterns: Event Bus

Filed under: Uncategorized — ketan @ 10:24 AM

Today, we are tackling something that is kind of new (and by that, I mean not mentioned in the GoF book), and that is the Event Bus.

Motivation

Imagine having a large scale application containing a lot of components interacting with each other, and you want a way to make your components communicate while maintaining loose coupling and separation of concerns principles, the Event Bus pattern can be a good solution for your problem.

The idea of an Event bus is actually quite similar to the Bus studied in Networking (Bus Topology). You have some kind of pipeline and computers connected to it, and whenever one of them sends a message, it’s dispatched to all of the others. Then, they decide if they want to consume the given message or just discard it.

Bus Networking Topology

At a component level, it’s quite similar: the computers are your application components, the message is the event or the data you want to communicate, and the pipeline is your EventBus object.

Implementation

There is no correct way to implement an Event Bus. I’m going to give a peak at two approaches here, finding other approaches is left as an exercise to the reader.

First Pattern

This one is kind of classic, as it relays on defining your EventBus interface (to force a given contract), implementing it the way you want, and defining a  Subscribable (another contract) to handle the Event(and yet another contract) consumption.

The Subscribable declares a method to handle a given type of objects and what type of objects it supports by defining the supports method .

The EventBus implementation holds a List of all the Subscribables and notifies all of them each time a new event comes to the  EventBusdispatch method .

Opting for this solution gives you compile time that checks the passed Subscribables, and also, it’s the more OO way of doing it, with no reflection magic needed, and as you can see, it can be easy to implement. The downside is that contract forcing thing — you always need a new class to handle a type of event, which might not be a problem at first, but as your project grows, you’re going to find it a little bit repetitive to create a class just to handle simple logic, such as logging or statistics.

Second Pattern

This pattern is inspired from Guava’s implementation, the EventBus implementation looks much simpler and easier to use. For every event consumer, you can just annotate a given method with @Subscribe and pass it an object of the type you want to consume (a single object/parameter), and you can register it as a message consumer by just calling eventBus.register(objectContainingTheMethod). To produce a new event, all you have to do is call eventBus.post(SomeObject) and all the interested consumers will be notified.

What happens if no consumer is found for a given object? Well, nothing really. In guava’s implementation, they call them DeadEvents; in my implementation, the call to post is just ignored .

You can see that opting for this solution requires less work on your part — nothing prevents you from naming your handler methods intention-revealing names rather than a general handle. And, you can define all your consumers on the same class. You just need to pass a different event type for each method.

Conclusion

Implementing an EventBus pattern can be beneficial for your code base as it helps loose coupling your classes and promotes a publish-subscribe pattern. It also help components interact without being aware of each other. Whichever implementation you choose to follow is a matter of taste and requirements.

All the code samples and implementation can be found in this repo.

from Javalobby https://ift.tt/2Oyh9Oq

November 10, 2018

Xbox One X will sell for $400 in week-long Black Friday sale

Filed under: Uncategorized — ketan @ 7:58 PM


Devindra Hardawar/Engadget

Tucked in amidst the flurry of Xbox One update and game news was one important tidbit: Microsoft is offering a steep discount on the Xbox One X in the very near future. It’s holding a Black Friday sale between November 18th and November 26th, and its 4K-capable console will sell for $400. That will be the “lowest price ever” for the system, Microsoft said. The company also promised $100 off an Xbox One S Minecraft bundle and $70 on other bundles (including one with Forza Horizon 4). Regardless of which system you buy, you’ll also get a free digital copy of Gears of War 4.

Microsoft is also promising deals on several games between November 22nd and November 30th, including Forza Horizon 4 (up to 35 percent off), Forza Motorsport 7 (as much as 50 percent off), PUBG (35 percent off) and Sea of Thieves (50 percent off).

It’s not surprising that Microsoft would slash the Xbox One X’s price in time for the Black Friday sales frenzy, but it’s notable just a year after the machine arrived. It also illustrates the competitive pressure going into the holiday. Sony is already selling the PS4 Pro for $400 before discounts, and the Xbox One X is no longer a shiny new system that can command a premium — this sale might be important to reel in buyers who could be focused more on price.

from Engadget https://ift.tt/2PoiwVc

November 8, 2018

Spring Boot in a Container

Filed under: Uncategorized — ketan @ 7:45 AM

Many people are using containers to wrap their Spring Boot applications, and building containers is not a simple thing to do. This is an article for developers of Spring Boot applications, and containers are not always a good abstraction for developers – they force you to learn about and think about very low level concerns – but you will on occasion be called on to create or use a container, so it pays to understand the building blocks. Here we aim to show you some of the choices you can make if you are faced with the prospect of needing to create your own container.

We will assume that you know how to create and build a basic Spring Boot application. If you don’t, go to one of the Getting Started Guides, for example the one on building a REST Service. Copy the code from there and practise with some of the ideas below. There is also a Getting Started Guide on Docker, which would also be a good starting point, but it doesn’t cover the range of choices that we have here, or in as much detail.

This blog is also a "topical" guide on the spring.io website. Visit it here for updates: https://spring.io/guides/topicals/spring-boot-docker/.

A Basic Dockerfile

A Spring Boot application is easy to convert into an executable JAR file. All the Getting Started Guides do this, and every app that you download from Spring Initializr will have a build step to create an executable JAR. With Maven you ./mvnw install and with Gradle you ./gradlew build. A basic Dockerfile to run that JAR would then look like this, at the top level of your project:

Dockerfile

FROM openjdk:8-jdk-alpine
VOLUME /tmp
ARG JAR_FILE
COPY ${JAR_FILE} app.jar
ENTRYPOINT ["java","-jar","/app.jar"]

The JAR_FILE could be passed in as part of the docker command (it will be different for Maven and Gradle). E.g. for Maven:

$ docker build --build-args=target/*.jar -t myorg/myapp .

and for Gradle:

$ docker build --build-args=build/libs/*.jar -t myorg/myapp .

Of course, once you have chosen a build system, you don’t need the ARG – you can just hard code the jar location. E.g. for Maven:

Dockerfile

FROM openjdk:8-jdk-alpine
VOLUME /tmp
COPY target/*.jar app.jar
ENTRYPOINT ["java","-jar","/app.jar"]

Then we can simply build an image with

$ docker build -t myorg/myapp .

and run it like this:

$ docker run -p 8080:8080 myorg/myapp
  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::        (v2.0.2.RELEASE)

Nov 06, 2018 2:45:16 PM org.springframework.boot.StartupInfoLogger logStarting
INFO: Starting Application v0.1.0 on b8469cdc9b87 with PID 1 (/app.jar started by root in /)
Nov 06, 2018 2:45:16 PM org.springframework.boot.SpringApplication logStartupProfileInfo
...

Notice that the base image is openjdk:8-jdk-alpine. The alpine images are smaller than the standard openjdk library images from Dockerhub. There is no official alpine image for Java 11 yet (AdoptOpenJDK had one for a while but it no longer appears on their Dockerhub page).

If you want to poke around inside the image you can open a shell in it like this (the base image does not have bash):

$ docker run -ti --entrypoint /bin/sh myorg/myapp
/ # ls
app.jar  dev      home     media    proc     run      srv      tmp      var
bin      etc      lib      mnt      root     sbin     sys      usr
/ #

The docker configuration is very simple so far, and the generated image is not very efficient. The docker image has a single filesystem layer with the fat jar in it, and every change we make to the application code changes that layer, which might be 10MB or more (even as much as 50MB for some apps). We can improve on that by splitting the JAR up into multiple layers.

A Better Dockerfile

A Spring Boot fat jar naturally has "layers" because of the way that the jar itself is packaged. If we unpack it first it will already be divided into external and internal dependencies. To do this in one step in the docker build, we need to unpack the jar first. For example (sticking with Maven, but the Gradle version is pretty similar):

$ mkdir target/dependency
$ (cd target/dependency; tar -zxf ../*.jar)
$ docker build -t myorg/myapp .

with this Dockerfile

Dockerfile

FROM openjdk:8-jdk-alpine
VOLUME /tmp
ARG DEPENDENCY=target/dependency
COPY ${DEPENDENCY}/BOOT-INF/lib /app/lib
COPY ${DEPENDENCY}/META-INF /app/META-INF
COPY ${DEPENDENCY}/BOOT-INF/classes /app
ENTRYPOINT ["java","-cp","app:app/lib/*","hello.Application"]

There are now 3 layers, with all the application resources in the later 2 layers. If the application dependencies don’t change, then the first layer (from BOOT-INF/lib) will not change, so the build will be faster, and so will the startup of the container at runtime as long as the base layers are already cached.

We used a hard-coded main application class hello.Application. This will probably be different for your application. You could parameterize it with another ARG if you wanted. You could also copy the Spring Boot fat JarLauncher into the image and use it to run the app – it would work and you wouldn’t need to specify the main class, but it would be a bit slower on startup.

Tweaks

If you want to start your app as quickly as possible (most people do) there are some tweaks you might consider. Here are some ideas:

  • Use the spring-context-indexer (link to docs). It’s not going to add much for small apps, but every little helps.

  • Don’t use actuators if you can afford not to.

  • Use Spring Boot 2.1 and Spring 5.1.

  • Fix the location of the
    Spring Boot config file(s)
    with spring.config.location (command line argument or System property etc.).

  • Switch off JMX – you probably don’t need it in a container – with spring.jmx.enabled=false

  • Run the JVM with -noverify. Also consider -XX:TieredStopAtLevel=1
    (that will slow down the JIT later at the expense of the saved startup time).

  • Use the container memory hints for Java 8: -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap. With Java 11 this is automatic by default.

Your app might not need a full CPU at runtime, but it will need multiple CPUs to start up as quickly as possible (at least 2, 4 are better). If you don’t mind a slower startup you could throttle the CPUs down below 4.

Multi-Stage Build

The Dockerfile above assumed that the fat JAR was already built on the command line. You can also do that step in docker using a multi-stage build, copying the result from one image to another. Example, using Maven:

Dockerfile

FROM openjdk:8-jdk-alpine as build
WORKDIR /workspace/app

COPY mvnw .
COPY .mvn .mvn
COPY pom.xml .
COPY src src

RUN ./mvnw install -DskipTests
RUN mkdir -p target/dependency && (cd target/dependency; jar -xf ../*.jar)

FROM openjdk:8-jdk-alpine
VOLUME /tmp
ARG DEPENDENCY=/workspace/app/target/dependency
COPY --from=build ${DEPENDENCY}/BOOT-INF/lib /app/lib
COPY --from=build ${DEPENDENCY}/META-INF /app/META-INF
COPY --from=build ${DEPENDENCY}/BOOT-INF/classes /app
ENTRYPOINT ["java","-cp","app:app/lib/*","hello.Application"]

The first image is labelled "build" and it is used to run Maven and build the fat jar, then unpack it. The unpacking could also be done by Maven or Gradle (this is the approach taken in the Getting Started Guide) – there really isn’t much difference, except that the build configuration would have to be edited and a plugin added.

Notice that the source code has been split into 4 layers. The later layers contain the build configuration and the source code for the app, and the earlier layers contain the build system itself (the Maven wrapper). This is a small optimization, and it also means that we don’t have to copy the target directory to a docker image, even a temporary one used for the build.

Every build where the source code changes will be slow because the Maven cache has to be re-created in the first RUN section. But you have a completely standalone build that anyone can run to get your application running as long as they have docker. That can be quite useful in some environments, e.g. where you need to share your code with people who don’t know Java.

Build Plugins

If you don’t want to call docker directly in your build, there is quite a rich set of plugins for Maven and Gradle that can do that work for you. Here are just a few.

Spotify Maven Plugin

The Spotify Maven Plugin is a popular choice. It requires the application developer to write a Dockerfile and then runs docker for you, just as if you were doing it on the command line. There are some configuration options for the docker image tag and other stuff, but it keeps the docker knowledge in your application concentrated in a Dockerfile, which many people like.

For really basic usage it will work out of the box with no extra configuration:

$ mvn com.spotify:dockerfile-maven-plugin:build
...
[INFO] Building Docker context /home/dsyer/dev/demo/workspace/gs-spring-boot-docker-complete
[INFO]
[INFO] Image will be built without a name
[INFO]
...
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 7.630 s
[INFO] Finished at: 2018-11-06T16:03:16+00:00
[INFO] Final Memory: 26M/595M
[INFO] ------------------------------------------------------------------------

That builds an anonymous docker image. We can tag it with docker on the command line now, or use Maven configuration to set it as the repository. Example (without changing the pom.xml):

$ mvn com.spotify:dockerfile-maven-plugin:build -Ddockerfile.repository=myorg/myapp

Or in the pom.xml:

pom.xml

<build>
    <plugins>
        <plugin>
            <groupId>com.spotify</groupId>
            <artifactId>dockerfile-maven-plugin</artifactId>
            <version>1.4.8</version>
            <configuration>
                <repository>myorg/${project.artifactId}</repository>
            </configuration>
        </plugin>
    </plugins>
</build>

Palantir Gradle Plugin

The Palantir Gradle Plugin works with a Dockerfile and it also is able to generate a Dockerfile for you, and then it runs docker as if you were running it on the command line.

First you need to import the plugin into your build.gradle:

build.gradle

buildscript {
    ...
    dependencies {
        ...
        classpath('gradle.plugin.com.palantir.gradle.docker:gradle-docker:0.13.0')
    }
}

and then finally you apply the plugin and call its task:

build.gradle

apply plugin: 'com.palantir.docker'

group = 'myorg'

bootJar {
    baseName = 'myapp'
    version =  '0.1.0'
}

task unpack(type: Copy) {
    dependsOn bootJar
    from(zipTree(tasks.bootJar.outputs.files.singleFile))
    into("build/dependency")
}
docker {
    name "${project.group}/${bootJar.baseName}"
    copySpec.from(tasks.unpack.outputs).into("dependency")
    buildArgs(['DEPENDENCY': "dependency"])
}

In this example we have chosen to unpack the Spring Boot fat jar in a specific location in the build directory, which is the root for the docker build. Then the multi-layer (not multi-stage) Dockerfile from above will work.

Jib Maven and Gradle Plugins

Google has an open source tool called Jib that is relatively new, but quite interesting for a number of reasons. Probably the most interesting thing is that you don’t need docker to run it – it builds the image using the same standard output as you get from docker build but doesn’t use docker unless you ask it to – so it works in environments where docker is not installed (not uncommon in build servers). You also don’t need a Dockerfile (it would be ignored anyway), or anything in your pom.xml to get an image built in Maven (Gradle would require you to at least install the plugin in build.gradle).

Another interesting feature of Jib is that it is opinionated about layers, and it optimizes them in a slightly different way than the multi-layer Dockerfile created above. Just like in the fat jar, Jib separates local application resources from dependencies, but it goes a step further and also puts snapshot dependencies into a separate layer, since they are more likely to change. There are configuration options for customizing the layout further.

Example with Maven (without changing the pom.xml):

$ mvn com.google.cloud.tools:jib-maven-plugin:build -Dimage=myorg/myapp

To run the above command you will need to have permission to push to Dockerhub under the myorg repository prefix. If you have authenticated with docker on the command line, that will work from your local ~/.docker configuration. You can also set up a Maven "server" authentication in your ~/.m2/settings.xml (the id of the repository ios significant):

settings.xml

    <server>
      <id>registry.hub.docker.com</id>
      <username>myorg</username>
      <password>...</password>
    </server>

There are other options, e.g. you can build locally against a docker daemon (like running docker on the command line), using the dockerBuild goal instead of build. Other container registries are also supported and for each one you will need to set up local authentication via docker or Maven settings.

The gradle plugin has similar features, once you have it in your build.gradle, e.g.

build.gradle

plugins {
  ...
  id 'com.google.cloud.tools.jib' version '0.9.11'
}

or in the older style used in the Getting Started Guides:

build.gradle

buildscript {
    repositories {
      maven {
        url "https://plugins.gradle.org/m2/"
      }
      mavenCentral()
    }
    dependencies {
        classpath('org.springframework.boot:spring-boot-gradle-plugin:2.0.5.RELEASE')
        classpath('com.google.cloud.tools.jib:com.google.cloud.tools.jib.gradle.plugin:0.9.11')
    }
}

and then you can build an image with

$ ./gradlew jib --image=myorg/myapp

As with the Maven build, if you have authenticated with docker on the command line, the image push will authenticate from your local ~/.docker configuration.

Continuous Integration

Automation is part of every application lifecycle these days (or should be). The tools that people use to do the automation tend to be quite good at just invoking the build system from the source code. So if that gets you a docker image, and the environment in the build agents is sufficiently aligned with developer’s own environment, that might be good enough. Authenticating to the docker registry is likely to be the biggest challenge, but there are features in all the automation tools to help with that.

However, sometimes it is better to leave container creation completely to an automation layer, in which case the user’s code might not need to be polluted. Container creation is tricky, and developers sometimes don’t really care about it. If the user code is cleaner there is more chance that a different tool can "do the right thing", applying security fixes, optimizing caches etc. There are multiple options for automation and they will all come with some features related to containers these days. We are just going to look at a couple.

Concourse

Concourse is a pipeline-based automation platform that can be used for CI and CD. It is heavily used inside Pivotal and the main authors of the project work there. Everything in Concourse is stateless and everything runs in a container, except the CLI. Since running containers is the main order of business for the automation pipelines, creating containers is well supported. The Docker Image Resource is responsible for keeping the output state of your build up to date, if it is a container image.

Here’s an example pipeline that builds a docker image for the sample above, assuming it is in github at myorg/myapp and has a Dockerfile at the root and a build task declaration in src/main/ci/build.yml:

resources:
- name: myapp
  type: git
  source:
    uri: https://github.com/myorg/myapp.git
- name: myapp-image
  type: docker-image
  source:
    email: 
    username: 
    password: 
    repository: myorg/myapp

jobs:
- name: main
  plan:
  - task: build
    file: myapp/src/main/ci/build.yml
  - put: myapp-image
    params:
      build: myapp

The structure of a pipeline is very declarative: you define "resources" (which are either input or output or both), and "jobs" (which use and apply actions to resources). If any of the input resources changes a new build is triggered. If any of the output resources changes during a job, then it is updated.

The pipeline could be defined in a different place than the application source code. And for a generic build setup the task declarations could be centralized or externalized as well. This allows some separation of concerns between development and automation, if that’s the way you roll.

Jenkins

Jenkins is another popular automation server. It has a huge range of features, but one that is the closest to the other automation samples here is the pipeline feature. Here’s a Jenkinsfile that builds a Spring Boot project with Maven and then uses a Dockerfile to build an image and push it to a repository:

Jenkinsfile

node {
    checkout scm
    sh './mvnw -B -DskipTests clean package'
    docker.build("myorg/myapp").push()
}

For a (realistic) docker repository that needs authentication in the build server, you can add credentials to the docker object above using docker.withCredentials(…​).

Buildpacks

Cloud Foundry has used containers internally for many years now, and part of the technology used to transform user code into containers is Build Packs, an idea originally borrowed from Heroku. The current generation of buildpacks (v2) generates generic binary output that is assembled into a container by the platform. The new generation of buildpacks (v3) is a collaboration between Heroku and other companies including Pivotal, and it builds container images directly and explicitly. This is very interesting for developers and operators. Developers don’t need to care so much about the details of how to build a container, but they can easily create one if they need to. Buildpacks also have lots of features for caching build results and dependencies, so often a buildpack will run much quicker than a native docker build. Operators can scan the containers to audit their contents and transform them to patch them for security updates. And you can run the buildpacks locally (e.g. on a developer machine, or in a CI service), or in a platform like Cloud Foundry.

The output from a buildpack lifecycle is a container image, but you don’t need docker or a Dockerfile, so it’s CI and automation friendly. The filesystem layers in the output image are controlled by the buildpack, and typically many optimizations will be made without the developer having to know or care about them. There is also an Application Binary Interface between the lower level layers, like the base image containing the operating system, and the upper layers, containing middleware and language specific dependencies. This makes it possible for a platform, like Cloud Foundry, to patch lower layers if there are security updates without affecting the integrity and functionality of the application.

To give you an idea of the features of a buildpack here is an example using the Pack CLI from the command line (it would work with the sample app we have been using in thus article, no need for a Dockerfile or any special build configuration):

$ pack build myorg/myapp --builder=nebhale/java-build --path=.
2018/11/07 09:54:48 Pulling builder image 'nebhale/java-build' (use --no-pull flag to skip this step)
2018/11/07 09:54:49 Selected run image 'packs/run' from stack 'io.buildpacks.stacks.bionic'
2018/11/07 09:54:49 Pulling run image 'packs/run' (use --no-pull flag to skip this step)
*** DETECTING:
2018/11/07 09:54:52 Group: Cloud Foundry OpenJDK Buildpack: pass | Cloud Foundry Build System Buildpack: pass | Cloud Foundry JVM Application Buildpack: pass
*** ANALYZING: Reading information from previous image for possible re-use
*** BUILDING:
-----> Cloud Foundry OpenJDK Buildpack 1.0.0-BUILD-SNAPSHOT
-----> OpenJDK JDK 1.8.192: Reusing cached dependency
-----> OpenJDK JRE 1.8.192: Reusing cached launch layer

-----> Cloud Foundry Build System Buildpack 1.0.0-BUILD-SNAPSHOT
-----> Using Maven wrapper
       Linking Maven Cache to /home/pack/.m2
-----> Building application
       Running /workspace/app/mvnw -Dmaven.test.skip=true package
...
---> Running in e6c4a94240c2
---> 4f3a96a4f38c
---> 4f3a96a4f38c
Successfully built 4f3a96a4f38c
Successfully tagged myorg/myapp:latest
$ docker run -p 8080:8080 myorg/myapp
  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::        (v2.0.5.RELEASE)

2018-11-07 09:41:06.390  INFO 1 --- [           main] hello.Application                        : Starting Application on 1989fb9a00a4 with PID 1 (/workspace/app/BOOT-INF/classes started by pack in /workspace/app)
...

The --builder is a docker image that runs the buildpack lifecycle – typically it would be a shared resource for all developers, or all developers on a single platform. This one is work in progress from Ben Hale, who maintains the older buildpacks for Cloud Foundry and is now working on the new generation. The output in this case went to the local docker daemon, but in an automation platform it could be a docker registry. Once the pack CLI reaches a stable release the default builder will probably do the same thing.

Knative

Another new project in the container and platform space is Knative. Knative is a lot of things, but if you are not familiar with it you can think of it as a building block for building a serverless platform. It is built on Kubernetes so ultimately it consumes container images, and turns them into applications or "services" on the platform. One of the main features it has, though, is the ability to consume source code and build the container for you, making it more developer and operator friendly. Knative Build is the component that does this and is itself a flexible platform for transforming user code into containers – you can do it in pretty much any way you like. Some templates are provided with common patterns like Maven and Gradle builds, and multi-stage docker builds using Kaniko. There is also a template that use Buildpacks which is very interesting for us, since buildpacks have always had good support for Spring Boot. Buildpacks on Knative are also the opinionated choice of Riff and Pivotal Function Service for transforming user functions into running serverless apps.

Closing

This article has presented a lot of options for building container images for Spring Boot applications. All of them are completely valid choices, and it is now up to you to decide which one you need. Your first question should be "do I really need to build a container image?" If the answer is "yes" then your choices will likely be driven by efficiency and cacheability, and by separation of concerns. Do you want to insulate developers from needing to know too much about how container images are created? Do you want to make developers responsible for updating images when operating system and middleware vulnerabilities neeed to be patched? Or maybe developers need complete control over the whole process and they have all the tools and knowledge they need.

from Spring https://ift.tt/2yTzLnh

November 6, 2018

ESP8266 Monitor Keeps an Eye on OctoPrint

Filed under: Uncategorized — ketan @ 8:28 AM

At this point, you’ve almost certainly heard of OctoPrint. The web-based control interface for 3D printers is especially popular for those who’s primary computers run on an operating system that has a penchant for occasionally imploding. Even if you aren’t laboring under that common software handicap, OctoPrint offers a wide away of compelling features. Perhaps chief among them the ability to monitor your printer over the network, and if you insist, over the Internet. But while OctoPrint provides the server side for getting your printer on the net, you’re on your own for the client.

Rather than using a web browser like some kind of peon, [David Payne] has come up with a very slick desktop OctoPrint monitor using the WeMos D1 Mini ESP8266 board. With an exceptionally low part count and housed in a (what else) 3D printed enclosure, this is a cheap and easy OctoPrint accessory that we suspect will be decorating many a hacker’s desk before too long.

The electronics are simple to the extreme, just hook the 4 wires of an 128×64 OLED I2C display to the appropriate pins of the ESP8266 board, and you’re ready to upload the Arduino code [David] has come up with.

His code is very polished, from using WiFiManager for initial network setup to providing its own web-based configuration menus to get the device linked up to your OctoPrint instance, [David] clearly wanted this to be as smooth an experience as possible for the end user. When the 3D printer isn’t working on a job, the monitor will even switch over to showing you the time and weather. We’ve seen commercial products that weren’t this user-friendly.

We also love the case design on this little gadget. While the aesthetics are perhaps debatable (sort of reminds us of the little fellows from Darwinia), we appreciate any functional print that doesn’t require supports. You’ll need to provide a couple of little screws to keep the back panel on, but other than that everything snaps into place.

Of course, you could always just use your smartphone to keep an eye on OctoPrint, and even if the remote management capabilities don’t grab your interest, there’s plenty of interesting plugins to keep you occupied.

from Hack a Day https://ift.tt/2QmBc4g

An OpenSCAD Mini-ITX Computer Case

Filed under: Uncategorized — ketan @ 7:48 AM

We’re no strangers to 3D printed enclosures here at Hackaday. From the plethora of printed Raspberry Pi cases out there to custom enclosures for electronic projects, small plastic boxes turn out to be an excellent application for desktop 3D printing. But as printers get bigger and filament gets cheaper, those little boxes don’t always need to be so little. We aren’t talking about running off boxes for your sneaker collection either, if you’ve got the time and the print volume, you could whip up an enclosure for your PC.

[Nirav Patel] writes in to share his impressive 3D printed Mini-ITX computer case project, which would be a neat enough trick in its own right, but he took the concept one step farther and made it a parametric design in OpenSCAD. This allows the user to input their particular hardware configuration and receive STL files for a bespoke case. The list of supported hardware isn’t that long yet, but with the OpenSCAD code up on GitHub and released under the BSD license, hopefully the community can improve on that as time goes on.

To keep things simple (and strong), [Nirav] implemented what he refers to as a “bucket” design. The majority of the case is a single print, which does take a long time (just shy of 40 hours on his Prusa i3 MK3), but nearly eliminates any post-printing assembly. Only the optional feet and the lid need to be printed separately. Threaded inserts are used throughout the design for mounting hardware, so you don’t run the risk of blowing out the printed holes during hardware changes or upgrades.

A particularly neat feature, and a testament to the power of OpenSCAD, is the fact that the case’s internal volume is calculated and embossed into the side of the design. Does this have any practical purpose? Not exactly, but [Nirav] thought it would be appealing to the Mini-ITX case modding community which apparently measures their accomplishments in liters of volume.

We’ve seen a 3D printed computer case before, but it used acrylic sheets and couldn’t be made without a large format printer. There’s something to be said for a project that can be completed on the hacker community’s favorite printer.

from Hack a Day https://ift.tt/2PgIOJ1

The Linux Throwie: Powering a Linux Server with a 0.3W Solar Panel

Filed under: Uncategorized — ketan @ 7:44 AM

Have you ever had one of those moments, when you’re rummaging through your spare parts heap, and have a rather bizarre project idea that you can’t quite get out of your head? You know, the ones that have no clear use, but simply demand to be born, of glass and steel and silicon?

This time, the stubborn idea in question was sort of like a solar-rechargeable LED throwie, but instead of a blinking light, it has a fully cloud-accessible embedded Linux server in the form of a Raspberry Pi 3 Model B+. Your choice of embedded Linux board should work — I just happen to have a lot of these due to a shipping error.

There were two main challenges here: First, it would have to combine the smallest practical combination of solar panel, power supply, and battery that could run the Raspberry Pi. Second, we’ll need to remotely activate and access the Pi regardless of where it is, as well as be able to connect it to WiFi without direct physical access. In this article we’ll be dealing with the first set of problems — stay tuned for the rest.

One time I stuck a bunch together to make a ‘Dyson Lampshade’, which is of course a Dyson Sphere rendered less large, less spherical, and more absurd.

Sipping on Solar

I approached the first challenge from the standpoint that the Raspberry Pi doesn’t need to be on all that often. An ESP8266 (Wemos D1 Mini) running NodeMCU can provide battery management, and receive commands over MQTT to activate it, while staying in deep sleep mode most of the time. This consumes very little power, allowing a small 5 volt solar module to trickle-charge a lithium battery large enough to power the server for a few hours of run time.

The solar modules are worth a quick mention. They are the LR0GC02 (PDF) from Sharp, designed to trickle charge a variety of mobile electronics. Unlike a lot of modules out there, they are both extremely well encapsulated and very thin (about 1mm). They also come with detailed specifications. A single 300mW module is enough for this project, but I used three in parallel during development to speed up various tests. This tiny solar power module would also have been an interesting choice.

Managing the power from these modules is where things get a little hairy. We have a 4-5V power source charging a lithium cell that has a nominal output voltage of 3.7V. Then we have an ESP8266 module, which runs at 3.3V but can accept higher through an integrated linear regulator, as long as you watch the dropout voltage. Finally, we need a 5V output that can be easily toggled to power the Raspberry Pi. Also it would be nice to have a 12V line for future expansion.

Magnificence of Modern Modules

Thankfully that all sounds worse than it actually is, and there are some very common modules that will sort this out for us:

From left to right: A USB lithium cell charger, a DC-DC boost converter, and a DC-DC buck converter. They cost about a US dollar each, which was great value!

The first stage is a USB lithium cell charging module. These accept the ~5 V output from our solar panels, and will safely charge a lithium cell. The output of the module is whatever the battery voltage is.

Next in line, I added a DC-DC boost converter module set to output 12V. These modules are better than 90% efficient, accept a range of voltages, and will output a fixed voltage that is set by a trimpot. The 12V output is connected to the linear regulator on the ESP8266. This way, even if the battery voltage drops below around 3.7V, it will continue to function. This is critical as the ESP8266 monitors the battery and switches the server on and off. If we were to connect its linear regulator directly to the battery output, it would shut down due to power loss while there was still quite a bit of usable power in the system. We do lose a bit of efficiency here, but the ESP8266 is off most of the time, so I can tolerate that.

The 12V output is then fed into a DC-DC buck converter to drop the voltage down to 5V for the Raspberry Pi. It’s important to use a buck converter with an enable pin, so we can control the output state using the ESP8266 later on. Otherwise you’ll need to add a MOSFET or similar to control the power output.

Responsible Battery Management

At this point, we have all the voltage levels we need, and charge control circuitry to prevent our battery from engaging in spontaneous unplanned combustion. However, when lithium cells are discharged too far, they cannot be safely charged again. We need to monitor the battery and prevent it from rendering itself into an unusual paperweight.

The solution is quite straightforward: the ESP8266 has an analog to digital converter. It can only accept up to 3.3V, and our battery can supply more than this, so I used a couple of 100kΩ resistors set up as a voltage divider to drop the voltage – we don’t exactly need high precision here.

To start our control program, I set a timer to run the ESP8266 for 11 seconds before sleeping for 10 minutes, this is plenty of time for the chip to check for commands online. Then, if the battery voltage is below 3.4 volts, it will immediately sleep for 16 minutes instead.


function checkvolt()
x = adc.read(0)
print (x)
	if x < 528 then
		print("low battery, sleeping longer")
		node.dsleep(960000000)
	end
end

checkvolt()

function sleeping()
    node.dsleep(600000000)
end

tmr.alarm(0,11000,0,sleeping)

Some rough calculations suggest that the module will consume an average of around 1.5 mA normally, and around 0.2mA if the battery is low. In reality there will be some current consumed by all the parts even while the system sleeps. I’m told that the sun shines at least once every month or so (I’ll check at some point), and the battery should not have trouble maintaining charge. In any case, if the former assumption is wrong, I have bigger problems to deal with.

Regulating the Voltage Regulator

Finally, we need to be able to control the output of 5V from the last voltage regulator. While I purchased a module that had an ‘enable’ pin available, there was no documentation as to how it worked, and the exact chip used in my module was unclear. Looking at datasheets for a few ICs from different DC-DC converters, it looked like it was probably an active-high enable pin that was pulled up with a resistor on the module.

I tried pulling it back down with a 50kΩ resistor, and the voltage output dropped to zero. Supplying 3.3 volts from one of the GPIO pins of the ESP8266 triggered the enable pin, and it output 5V again.

I discharged the battery a little, then left it running in the sun for an hour – it recharged a bit as expected, prompting the requisite maniacal laughter. Power stages… complete!

Where’s the Linux?

It’s small, it’s solar powered, but other than lounging about in the sun, it doesn’t really do anything yet. Most computing hardware requires software and obviously this is no exception — so how do we make this into a lean, green, Linux machine?

In the next article, we’ll cover how to control this system via MQTT, set up remote configuration (for example if I need to change my WiFi password), and set up a reverse-SSH tunnel so we can connect to the Raspberry Pi without having to reconfigure our network to accommodate it.

The irony that my servers now get more sun than I do is not lost on me. I live near the equator though, and sunbathing for extended periods is an activity reserved for tourists – one that they normally learn to avoid pretty quickly!

from Hack a Day https://ift.tt/2DlrYSQ

Blog at WordPress.com.