The Hecklers
"Two roads diverged in a wood, and I took the one less traveled by and that has made all the difference."

When I got my first Raspberry Pi Model B (not long after they first became available – remember when they only had 256M?!?), I wanted to configure it to use a wifi adapter. Even with approved, compliant adapters, this wasn’t for the faint of heart; many steps, scripts, and secret incantations were required to get everything to connect, even in the best of circumstances.

 

Fast-forward to today, when wifi adapter drivers are included in the base Raspbian build. It’s relatively simple to connect to wifi networks that broadcast their SSIDs. Ah, but what about those with hidden SSIDs? Not so much.

 

Many sites have documented ways to get around this. The problem is that I’ve tried several of them without success, so I always return to my original settings – and they still work just as well as the day I put them together. So to save myself (and hopefully you, if you’re reading this post!) a great deal of time in the future, here is the shortest path I’ve found to configuring your Raspbian-running Pi to connect to a wifi network that doesn’t broadcast its SSID.

raspberry-pi-wireless

The Secret Sauce Steps

0. Log into your Pi (default user ID: pi, default password: raspberry).

Edit the network interfaces file

1. cd /etc/network

2. sudo cp interfaces interfaces.orig (this makes a backup copy of your interfaces file)

3. sudo vi interfaces (feel free to use a different editor if vi isn’t your cup of tea)

4. Edit your interfaces file to look like this:

 

5. Save the interfaces file.

 

Edit wpa_supplicant

1. cd /etc/wpa_supplicant

2. sudo cp wpa_supplicant.conf wpa_supplicant.conf.orig

3. sudo vi wpa_supplicant.conf

4. Edit your wpa_supplicant file to look like this:

 

5. Save the wpa_supplicant.conf file.

 

NOTE: If you have another network entry in this file (e.g. for a guest network), be sure to place this line in its entry to prevent its use:

 

Test

  • sudo reboot
  • Login once prompted.
  • ifconfig -a

If it’s working properly, your wlan0 adapter will show a valid IP address, a number of bytes and packets received and sent (RX and TX), and several other useful bits of information.

That’s all, folks

I’ve used this with three different wifi adapters, and it’s worked every time. Hopefully, it will work for you as well.

 

If you found this useful (or not, clear or confusing, etc.), please let me know. Good luck, and enjoy your Pi!

 

Keep coding,
Mark

Share

Tags: , , , , ,

Intro

I started this post a couple months ago, and between a busy holiday season and constant revisions, I’m only now polishing and posting it. For those who knew it was in the pipeline, thank you for your patience. :)

I have another article in the works that will delve into more technical aspects of the microservices discussion; hopefully I’ll get that posted by this time next year (!). In this one, though, I’d like to stay as much as possible at the conceptual level, dipping into the details only to reference them for consideration and future discussion. No guarantees, but that’s the plan. :)

Discussion

First, a good-natured poke at our discipline in general…

The Holy Grail

The Holy Grail of Software Development

Regardless of the new architecture, technique, methodology, framework, language/feature, etc., we (as developers) often fall prey to the temptation to make it a “one size fits all” solution. Regardless of the problem at hand, we break out our new toy, er, tool and apply it vigorously, without the benefit of objective consideration of suitability to the task at hand. To paraphrase two Abrahams (Kaplan and Maslow) the way I’ve always heard it:

“To the man with a hammer, everything looks like a nail.”

This doesn’t have anything to do with microservices directly…only with the fawning attitude for the concept that seems to be prevalent at the moment. :)

Along those same lines, I’d like to issue a couple of disclaimers here. I work for Oracle, so my experiences and worldview may differ from yours. That said, I like to think of myself as a fairly fact-based being; while I have been wrong many times and shall be again (many times), I do my best to analyze and come to conclusions based upon objective measures and reasoned assessments. Really, I do.

Secondly, it is incredibly difficult to make statements about microservices or anything else within the dev sphere that are 100% accurate and/or conclusive. I’ve tried to avoid blanket generalizations, but frankly, it’s nearly impossible to discuss anything without making some sweeping statements that one assumes/hopes will be understood as they were intended. If something below puzzles you or doesn’t sound right, please drop me a line and ask.

And finally, the views expressed in this post are mine and don’t represent those of Oracle. Or maybe anyone else. They’re just mine. :)

Now, back to microservices!

As with any tool applied indiscriminately to all problems, fit is often imperfect. Let’s take a closer look at what microservices are, what they’re up against, and their particular strengths and weaknesses.

Definitions

Microservices

“…the microservice architectural style…is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.”
Martin Fowler

Let’s dissect this a bit.

“…the microservice architectural style…is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.”

This is a good start. Without going overboard trying to explain something that is fairly straightforward, we’re talking about breaking down a large, complex application into small(ish – we’ll get to that a bit later) services that are more granular. Doing so should enable us to focus upon a more specific outcome for each portion of the overall functionality, which should result in better component manageability and quality.

“These services are built around business capabilities and independently deployable by fully automated deployment machinery.”

With all respect to Mr. Fowler, this bit of text is not specific to microservices. Capability-driven development approaches are used in many different contexts, and automated deployment is even less useful as a differentiator. For this discussion, we’ll ignore this bit of text entirely.

“There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.”

Unlike the previous statement, this is a very useful description of microservices that, while not entirely unique to them, lays out two key tenets:

  • Microservices are decentralized. They could be hosted anywhere.
  • Microservices are heterogeneous. They can be written in the developers’ language of choice and deployed on their platform of choice, as long as the “connections” are properly made.

The “Alternative(s)”

Everything else, of course. :)

The microservices concept primarily addresses the server side of the equation; the client component is a player only insofar as it is involved in the delivery of the application’s functionality. In the strictest sense, microservices focus upon the delivery of capabilities via (micro)services provided by server(s).

Keeping that same specific focus, the alternative is really the “monolithic” application, typically delivered as a single unit containing all functionality for the entire set of targeted use cases. Some means of delivering so-called monolithic applications include (but are not limited to) Java EE, .NET, or any other server-side environment that provides functionality to the user via an application server or an affiliated cluster of app servers.

Pros of a Microservices Architecture

Manageability

Firstly, anyone who has struggled under the weight of a large server-based application can immediately see the appeal of microservices. Monolithic apps can get “too big”, becoming unwieldy to develop and maintain. With so much complexity in a single code base, it becomes difficult to test, debug, etc. without the law of unintended consequences wreaking havoc in novel ways.

Extensibility

With a microservices architecture, functionality can be “farmed out” and provided by others, often developers/teams who don’t even work for your organization. While this isn’t unique to microservices, the architecture certainly facilitates it; creating and documenting the interfaces within the core app to support various connection points makes developing and integrating external functionality far easier for those outside the core application’s dev team than any monolithic app could be.

Location/Scalability

This also allows hosted functionality to be geographically dispersed more readily than typical alternatives, deploying microservices wherever it makes sense to do so (using any criteria). If a development partner on one side of the world decided to provide a microservice that integrates with a core application hosted on the other, this could be done easily by complying with published interface standards and requirements. Adding an external functionality provider is far less disruptive to the core app if it was designed with that end in mind, and that is the core principle of a microservice architecture (see above).

Granularity

Creating an application with microservices in mind also can result in a leaner core application. It’s an imperfect analogy, but composition vs. inheritance applies here. If your architecture embraces the creation of a core set of functionality with numerous extension points, your core app potentially can be more focused and functionally cohesive…as can each microservice.

Cons of a Microservices Architecture

Any architectural decision has its downside, and a microservices architecture creates new challenges while it’s solving old ones. Here are a few potential hurdles that microservices face.

Control

If you thought debugging and testing a monolithic application was a challenge – with all code directly accessible and modifiable (to varying extents) from the comfort of your IDE – you’re probably cringing at the thought of your pending inability to sink your hands into the entire codebase to fix bugs that surface or (more) easily test and diagnose aberrant behavior that is reported in your app. End-users will not know (and won’t care) that something breaks due to a partner’s error in implementing an interface, failure to completely debug an edge case, or even an innovative misuse of the app by said user. Your app is broken, #fail.

Consistency

If portions of your application’s functionality are provided by other groups or organizations, maintaining consistency becomes more difficult. User interfaces, error handling, text phrasing…these are just a few examples of areas where small differences can make a huge impact on the overall user experience.

Overhead

Say what you will about about monolithic apps, but infrastructure and interfaces are costs that are borne once for the entire (monolithic) application…to say nothing of transactions. When portions of your app’s functionality are provided via microservices hosted on various external platforms, connection security and authentication/authorization must be factored into the most insignificant internal interactions. It’s only a bit of an exaggeration to say that with a microservices architecture, there are no local interfaces. And for those who think “microservices” means “tiny services”, there is no limit to the size/scope of a so-called microservice. Factoring in the overhead, they can involve more code than you might expect, somewhat negating some of the advantages of “leanness” you may have been anticipating.

Fragility

With multiple infrastructures and databases potentially hosted on various platforms in far-flung places, a microservices-based application certainly offers more breakpoints. At best, this introduces latency concerns; at worst, fragility. If any key bits of functionality are delivered via an (external) microservice, the unavailability of that microservice breaks your app. This is less of a concern if the group supporting the failed service is just down the hallway; but if the other organization is in a different building, city, or country, small breakages can quickly result in painful outages and even lost customers. See the note about Control above.

In Conclusion (For Now)

A microservices architecture offers another viable approach, another option to deliver more functionality to end-users…but it is not a silver bullet.

A microservices architecture can provide greater flexibility and code quality by capability at the possible expense of (overall) application availability and control. It’s a great tool, used wisely and in the right circumstances…but as with any great tool, it doesn’t remove the responsibility to think prior to (and while) employing it.

Now, go develop something. :)

Cheers,
Mark

 

Share

Tags: , , , , , , , , ,

JavaOne: I'm Speaking

 

There are some absolutely SUPERB conferences dedicated to Java (the language, the platform, the ecosystem) around the world, and I’ve been privileged to speak at some of them. No two are alike, and that is a good thing! JavaOne San Francisco holds a very special place in that lineup, bringing together a phenomenal mixture of vision, direction, community leadership, and grassroots innovation that is nearly impossible to describe. You just have to be there!

 

This year I’m pleased and honored to be presenting in three sessions, sharing the stage with some of my favorite people from around the world: Jim Weaver, Sean Phillips, David Heffelfinger, Geertjan Wielenga, Jens Deters, José Pereda, and James Gosling. As I said, it’s a genuine honor!

 

Here are the sessions in which I’ll be taking part:


Creating Our Robot Overlords: Autonomous Drone Development with Java and the Internet of Things [CON1863]
Tuesday, Sep 30, 2:30 PM – 3:30 PM – Hilton – Continental Ballroom 4

Who wants a mindless drone? Teach it to “think,” and it can do so much more. But how do you take it from Toy Story to Terminator? This session’s speakers discuss their new open source library, Autonomous4j, for autonomous drone development. Combining this library and some components from their mad science toolkit, they demonstrate how to get your Internet of Things off the ground and do some real cloud computing. In the session, you’ll learn how to write an autonomous drone program with Java 8; deploy it to the drone’s “positronic brain,” an onboard Raspberry Pi; have the Pi guide an AR.Drone to accomplish a task; monitor it via a JavaFX console; and create your own robot overlord. Demos are included: you’ve been warned!

With Jim Weaver & Sean Phillips


Debugging and Profiling Robots with James Gosling [CON6699]
Wednesday, Oct 1, 1:00 PM – 2:00 PM – Hilton – Continental Ballroom 4

James Gosling recently stated that “being able to debug and profile robots out at sea is a truly life-altering experience.” He uses a set of tools—consisting of editors, debuggers, and profilers—that are part of the NetBeans IDE. In this session, Gosling and other speakers introduce you to these tools and show you how easily and quickly you can program and interact with devices via Java tools. Come see how well integrated embedded devices are with the Java ecosystem.

With Geertjan Wielenga, Jens Deters, José Pereda, & James Gosling


Java Platform, Enterprise Edition Lab 101: An Introduction [HOL1827]
Wednesday, Oct 1, 10:00 AM – 12:00 PM – Hilton – Franciscan A/B

For anyone familiar with the Java language but without direct Java Platform, Enterprise Edition (Java EE) experience, the capabilities and APIs in Java EE can seem daunting. Documentation is helpful, and well-written books can make it easier to come up to speed, but isn’t the best way to learn something to actually do it? This session’s speakers hope to smooth the path for anyone curious about Java EE by offering a gentle, yet useful, introduction to four key concepts:

 

• JavaServer Faces (JSF)
• Contexts and Dependency Injection (CDI)
• Java Persistence API (JPA)
• Enterprise JavaBeans (EJB)

 

Using NetBeans and the bundled GlassFish application server, the speakers present each new concept with live code and then help attendees complete hands-on exercises.

With David Heffelfinger (and gracious assistance from Sven Reimers, Josh Juneau, Bob Larsen, & Bruno Borges)


I’ve said it before: There’s no better place to see what’s happening in the world of Java than JavaOne. Hope to see you there!

 

All the best,
Mark

 

Cross-posted from The Java Jungle.

Share

Tags: , , , , , , , , , ,

We had to postpone it last month, but it’s ON!

 

MarkToon

 

The full details behind the idea and planned execution can be found here (HackFest – Thanks For Sharing!), but to quote one of my favorite movies of all time, “Let me sum up”: this is an unofficial, un-sponsored-by-anyone virtual gathering of friends and soon-to-be-friends just pounding away on their Java code. JavaFX? Sure! Java SE or ME Embedded? Check. Another JVM language? Bring it! Join into a planned project (Hendrik Ebbers is cooking up something special for any who’d like to contribute to it) or BYOP – Bring Your Own Project. Whether you’re diving to new depths in a familiar area or tinkering with a new idea or API, it’s all fair game.

 

I plan to set up a Google Hangout and keep it open for the duration. Join in for as long (or as little) as you like! Here are the details:

 

Begins: 1200 (noon) UTC/GMT on Saturday, November 16th
Ends: 1200 (noon) UTC/GMT on Sunday, November 17th
Where: Google Hangouts

Calendar reminder and invite will be sent to all who want to join in the fun.

 

Please spread the word (it’s easy, just use the Share/Save button below), and let me know if you can attend, whether for a half hour or all 24! Just email me here to “sign up” and be kept in the loop of any updates, new news, or post-HackFest (subsequent HackFest(s)?) announcements. Looking forward to hearing from you (yes, YOU!) and hanging out, learning, growing, & sharing.

 

Keep that (Java) code flowing!
Mark

Share

Tags: , , , , , , , , , , , , , , , , ,

I’ve been testing various “embedded platforms” lately to provide infrastructure for my IoT configurations. In doing so, I’ve installed and configured the GlassFish 4 Web Profile to run successfully on the Raspberry Pi Model B (512M). This post is not meant to be exhaustive or even necessarily prescriptive, but rather an iterative log of what I’ve done and do to configure a Raspberry Pi to “run with the big dogs”, i.e. Java Enterprise Edition (EE) 7.

GlassFish 4

Raspberry Pi Logo

Please check back (or subscribe to my RSS feed for IoT) to monitor updates. The Internet of Things (IoT) is a very dynamic space and will likely remain so for some time! The only constant…is change.  😀

Document version 1.3 (This number will change as I make updates and is for reference only)

Steps to Install/Configure GlassFish 4 on the Raspberry Pi

  1. Download the latest version of Raspbian Wheezy from here. You can install NOOBS, Arch, or some other distro, but I chose Raspbian. Note that this distro includes the Java SE 7 JDK, which simplifies things a bit. If you wish to use an previous Raspbian build that doesn’t already include the JDK, simply run “sudo apt-get update && sudo apt-get install oracle-java7-jdk” from your Pi shell.
  2. Make a bootable SD card by doing the following (on my Mac; Windows steps will vary a bit):
    1. Unzip/decompress the downloaded image from step 1
    2. Open a Mac terminal window
    3. Run “diskutil list” to see drives
    4. Plug SD card into SD card slot
    5. Again run “diskutil list” to see drives, now including the SD card
    6. Run “sudo diskutil unmountDisk /dev/diskn“, where n is the disk number of the SD card (as reported by diskutil)
    7. Issue the following command, being very careful to ensure the of= parameter points to the SD card! If not, you can overwrite something you’d rather not…like your boot drive: “sudo dd if=<path/name_of_Raspbian_image.img> of=/dev/diskn bs=1m”
    8. Once dd completes, issue “diskutil eject /dev/diskn” to eject the SD card
  3. Plug the SD card into the Pi, plug ethernet cable and power into the Pi to boot.
  4. At this point, you’ll need to determine current (dynamic) IP address of the Pi. I plugged in my Atrix Lapdock and did this “on the Pi”, but you can also use nmap or connect it to HDMI (TV) and USB keyboard.
  5. Run “sudo raspi-config” and set the following:
    1. Expand the file system to take the entire SD card (not just what the image initially does)
    2. Under Internationalisation Options, change Locale, Timezone, & Keyboard layout as desired
    3. Overclock to High (950MHz). I’ve tried Turbo, but it seems prone to flakiness & data loss…at least for me.
    4. Under Advanced Options, change Hostname to desired Pi name, Memory Split to 16 (as a server, we can skinny the GPU memory allocation to maximize “main” memory), and enable SSH. You can also “Update this tool” (raspi-config) to the latest version, never a bad thing.
    5. Select “Finish” to reboot the Pi & use the new settings
  6. Ensure the Pi has a static IP by doing the following (recommended for any server):
    1. Run “ifconfig -a” and “netstat -nr” on the Pi to gather the following information: current IP (if you want to keep it), netmask, gateway, destination, and broadcast. Jot these down.
    2. Make a backup of /etc/network/interfaces by running “sudo cp /etc/network/interfaces /etc/network/interfaces.orig
    3. Modify the interfaces file. I used vi, but use whatever editor you can & are comfortable with! The vi syntax is “sudo vi /etc/network/interfaces”
    4. Change the line that reads “iface eth0 inet dhcp” to “iface eth0 inet static” and add the following lines:
      • address 192.168.1.nnn (this is the IP address you want the Pi to have & keep)
      • netmask 255.255.255.0 (or whatever was shown in ifconfig -a above)
      • network 192.168.1.0 (or whatever was in the destination column, 2nd line from netstat -nr above)
      • broadcast 192.168.1.255 (as shown in ifconfig -a)
      • gateway 192.168.1.1 (or what was shown in either ifconfig or netstat)
    5. Save the file
    6. Reboot the Pi (“sudo reboot”)
    7. NOTE: You’ll also need to tell your network DHCP device/router that the IP address you statically assigned to the Pi is off-limits for assigning to another device
  7. Download GlassFish 4 Web Profile (or full EE platform) from here. I chose the Zip installer.
  8. Copy the GlassFish .zip file to the Pi (“scp glassfish-4.0-web.zip pi@raspi:.”). I have an entry in my Mac’s /etc/hosts that points “raspi” to the Pi’s static IP address.
  9. On the Pi, “install” GlassFish by doing the following:
    1. Run “sudo mkdir -p /app/glassfish” to create GlassFish app parent directory
    2. Run “sudo chown pi /app/glassfish” to assign directory ownership to the pi user. Not absolutely necessary, but you typically don’t want root to own everything (although honestly at this stage & for this install, it’s not critical)
    3. “cd /app/glassfish” as the pi user to change directories into the “install” directory
    4. Run “unzip ~/glassfish-4.0-web.zip” to extract the GF files into this directory
  10. Now to configure GF to allow for remote administration/configuration using its web console app:
    1. “cd /app/glassfish/glassfish4/bin”
    2. Run “./asadmin change-admin-password --user admin” to assign a password to the admin user. The admin password defaults to a blank password, a no-no for GF remote admin.
    3. Run “./asadmin start-domain” to start the default domain (which comes preconfigured in GF)
    4. Run “./asadmin enable-secure-admin” to enable remote administration using the web console
    5. In order to take utilize remote admin, stop the domain by running “./asadmin stop-domain”, then…
    6. Start the domain once more with “./asadmin start-domain”
  11. From your workstation/laptop, plug this into a browser address bar: “raspi:4848″ (substituting the name of your Pi per your /etc/hosts file) or “192.168.1.n:4848″ (substituting the IP address or your Pi) to load the GF admin console
  12. Login and relish the fact that you now have a full Java EE 7 stack (or web profile) running on your Raspberry Pi server!

I’m capturing this from memory, so it’s possible I’ve missed a step I performed or have related it not-exactly-perfectly…but if you spot something that isn’t quite right or have questions, please let me know! I’ll update this document accordingly. YMMV (Your Mileage May Vary), especially if you’re using a Linux or Windows machine for your workstation, but hopefully, this will get you that much closer to your own tiny Java EE 7 stack for your own growing IoT empire.

All the best,
Mark

P.S. – Follow me on Twitter at @MkHeck for more Java/IoT adventures…yours and mine (and ours)!

Share

Tags: , , , , , , , , , , , ,

Powered by Wordpress
Theme © 2005 - 2009 FrederikM.de
BlueMod is a modification of the blueblog_DE Theme by Oliver Wunder