Thursday, June 1, 2017

Pre-Google I/O Entertainment: Old Electronics Stores and Computer Resellers!

The opportunity Google gave me to attend Google I/O, their annual conference, two weeks ago required me to travel to the Bay Area in California in order to attend in person.  Also known as Silicon Valley, it is an area steeped in computer history, featuring (of course) the Computer History Museum, not to mention large offices or global headquarters for many current and long-gone tech behemoths, plus all the tiny startups making millions off various Internet and mobile technologies.  As someone who has been using computers their entire life (well over 25 years now), I am enthusiastic about the way forward but do not want to forget about the winding, bumpy way that has gotten us to this point.

As I seek to bolster my collection of retro-tech, it is fascinating to pontificate on what all these devices would have cost brand new.  There's no way my family could have afforded but one or two these things back in the day, but as technology marches on and leaves so much of itself in the dust, follow along with me as I walk through some of the few remaining stores and shops dedicated to the Hardware Era of Silicon Valley.


Definitely not where Google I/O was.

However, pretty much right across the street from this Yahoo! building was the first stop on my tour after picking up my Google I/O badge: Weird Stuff Warehouse.  Not having been into such a computer surplus/resale store, I was filled with just about as much wonderment as I was upon walking into my first neighborhood computer store back in 2000 (let's just say it was much better than most neighborhood computer stores, and certainly a different experience from the big box retailers).  Upon walking in, you are greeted with about four aisles of tested working stuff of all kinds, including computers & parts, video equipment, and other assorted electronics.  There are several counters and associates waiting to offer help in this area.  That might not sound like much, but wait; it gets more interesting.



Behind this "Open to the public" sign (actually right where I'm standing when I took this picture), at the far corner of the first room from the entrance, is a whole plethora of aisles in their "As-is" section devoted to old software, I/O cards of all kinds, computer peripherals, cables, test equipment, server racks, typewriters, old telephony equipment, hard drives, floppy drives, CD/DVD drives, tape drives of all types, and even the obscure media that goes with these tape drives.




Some of the aisles in the "As-is" section of WeirdStuff Warehouse.

It is difficult to convey through pictures just how much there is to look at here because from the camera's perspective, it all disappears into the vanishing point so quickly, and so many of the bins are very small.  But after about three or four hours perusing Weird Stuff trying to pick as much SCSI components as I could muster, I had one of their associates search for some interesting stuff out of the back (namely more SCSI drives).  As it turns out, most folks say that they don't have everything necessarily out on display nor listed on their website; generally the stuff listed on their website isn't out in the aisles available to be browsed in-person.  Also, one of the guys from the Vintage Computer Forums says he's got a standing order with WeirdStuff where they'll let him know if they get anything on his wish list.  What a neat service that could be, but I'd hate (love?) to see how much stuff he's ended up with over the years!  Anyway, once I was through, I hailed another Lyft ride who whisked me on to Anchor Electronics.

Because when I think Anchor, or Electronics, I think "wire-frame dirigible..." ?!?

Anchor is in a small building right across the street from the southeast corner of the NVIDIA offices.  Walking into Anchor for the first time, it really felt like more of a typical electronic component store (i.e. more like a well-stocked Radio Shack) than WeirdStuff.  Everything in Anchor was some sort of component or tool neatly organized on their shelves.  I didn't really have a lot of time to browse around, having only about 25 minutes there before they closed, but I also wasn't really in need of components either.  They do happen to have various protoboards for everything from ISA to Arduino shields, and a small smattering of Atari 8-bit parts, of interest to vintage computer folks, but I'm really more interested in Atari ST (Sixteen/Thirty-two) systems; they don't carry those types of parts.  I did manage to get into a discussion with another fellow in the store and their main technical support guy Orville by helping brainstorm solutions for some short-distance presence detection type of application, and Orville was interested that his store was one of my primary sights to see in the Valley.  However, it was closing time, and I needed to leave.



Scenes from inside Anchor Electronics, a relatively small but dense store, including the one telling me it's time to go!

Now I was a bit split.  Do I take another Lyft down into San Jose to Excess Electronics and contend with tons of Silicon Valley traffic, or do I just take what's convenient?  Ultimately, Excess will just have to wait until next time, as Orville ended up driving me to my next destination just a few minutes after close; this would be HSC Electronics.  Along the short 1.5-mile journey there, Orville pointed out all sorts of buildings along the street that house famous names now but held other large names 10, 20, or 30 years ago that have since gone extinct -- most notably, the Qualcomm building on Kifer Road real close to HSC that formerly housed 3Com.

HSC is a really big electronic component store that, as much as I love Tanner's in Dallas, makes Tanner look like an itty-bitty Radio Shack in comparison to a great big Fry's store.  The fellows at HSC were also very cordial, and Orville was also buddies with them (and possibly performing a bit of reconnaissance on the competition... you never know!).  Once I expressed my interest in old computers with them such as the Amiga and Atari, they brought out some oddities for me to see: the KIM-1 (1976's version of a Raspberry Pi) and another old-time single-board computer I can't remember now but was based on the Motorola 6800 series processors if I can recall correctly.  And then they showed me a real claim to fame for their store:


Gee, some no-name hack from San Francisco bought an oscilloscope from them.  Who gives? :-P

No, seriously, look closely at that picture above.  If you're not impressed that somewhere, someone was keeping records at HSC for years and years and remembered that kid when he got famous, then I don't know what to tell you.  However, they said the same thing to me (more or less "remember us when you're famous"), though they don't have my name scribbled on a nice large "Name" field like they would have done if I walked into that store back in the '60s too.  Chances are they might have it on some way less interesting credit card log somewhere, but who's to know.

Nevertheless, I spent quite a while browsing this store too, firstly in sheer awe that the arrangement resembles Tanner's so much (but with aisles twice as high, and many more of them) and secondly trying to jog my memory for stuff I could possibly need.


The test bench section and the Self-Serve wire area.  They only ask a couple reasonable things of the test area: let them know ahead of time if you're testing anything with vacuum tubes, and don't leave hot leads lying around.



Aisles upon aisles of stuff, including one barely wider than my shoulders.  Also, mind you, I was homeless most of the day, having checked out of my hotel early that morning and not able to check into the rental house until that evening; as such, I was having to carry all my bags, toiletries, clothes, and my purchases with me at all times up and down the aisles.



Putting All This In Perspective


First off, without the assistance of Raymond, a local buddy of mine who runs arcadecomponents.com and travels out to these stores relatively often (and who also contributed to this relevant thread on the Vintage Computer Forums), I probably would have ended up in some lame stores that wouldn't pay such homage to retro technology and would only be looking to resell last year's Cisco servers, or else some general vintage store that once upon a time had a computer section but now only mostly sells hipster clothes and occasionally gets someone's old laptop once in a great while.  Nevertheless, here is how all these things fit together physically:

It should be noted that Raymond highly recommended St. John's Bar & Grill as a good place to have a burger, especially if you need to ship some of your larger hauls via the FedEx in the same complex.



Also Intriguing To the Music Nerd


For those of you who happen to be band nerds too, it should be noted that the Santa Clara Vanguard, an extremely competitive and highly-ranked drum and bugle corps and an original member of DCI (Drum Corps International), has their headquarters little more than half a mile north of Anchor Electronics, just on the other side of the NVIDIA offices.  If I were ever good enough to make that corps when I was in school, it would have been awfully intriguing for me to explore the tech scene whenever (if ever?) I had a break from practice, though in actuality I can't imagine the members really spending much time in that office compared to out on the rehearsal field or traveling anyway.

Thursday, May 18, 2017

Moments Inside Google I/O 2017

Google I/O 2017 is the highly-anticipated and much-improved follow-on edition of Google I/O 2016.  It's evident throughout all aspects of the conference that they took feedback and lessons learned from last year's maiden foray into the Shoreline Amphitheater to make for a much more awesome experience.  Now, I sit here writing this to you from inside the Amphitheatre itself, comfortable in just a thin long-sleeve shirt and jeans, no wind at all (unlike last year), awash in sound from the LCD Soundsystem.  However, I almost didn't write you this story.


A Nearly Missed Opportunity


The registration window for I/O 17 came upon us.  Stacy reminded me it was time for this, but I balked at the price -- up $150 from last year!  Nevertheless, I still planned to register... until I didn't.  I hadn't realized I forgot until a day after registration closed.  My heart fell through the floor, and Stacy rolled her eyes... Oh Stevo... Oh well... I thought all hope was lost until she told me of an opportunity to try again for another shot at a ticket through the Women Techmakers raffle.  I applied for the raffle dutifully -- it's never fun to fill out the long Google I/O registration form though -- but knowing it was my only shot, it needed to get done.  Fast forward just a couple days later, April 18, tax day, and on a day when I was about to spend about $12,000 between car repairs and the tax bill... well, I got debited another $750 when I won the raffle.  Now that actually felt good, because it was $300 off the regular ticket price anyway!


What to Do In the Bay Area


Prior to the event, besides bumming around San Francisco while Stacy participated in various Women Techmakers events (and all the touristy stuff that entails) (except for how I actually wandered through the Tenderloin district once accidentally and a couple times on purpose), I spent a significant part of "Day Zero" wandering around the Sunnyvale area hitting up old-time electronics stores still leftover from the days when hardware companies ruled Silicon Valley and software was something you crammed onto a tiny PROM chip if you were lucky.  (But more on that possibly next week... I have to make sure I'm clear to post some of those pictures, plus Google I/O is timely this week!)

Anyway, there are some "Zero-Day" parties sponsored by companies participating in Google I/O.  I scored invitations and tickets to the Netflix party and, for the second year, the Intel IoT party.  The night started with the Netflix party for me, which I arrived at after dropping off my haul from all the old electronics and computer stores.  It was at the Computer History Museum in Mountain View, very close to the Googleplex.  It is a cool museum, but unfortunately most of the people there seemed to already be in their little cliques and didn't seem too terribly interested in talking to a guy with a cool homemade LED badge.  It's kind of sad how insular a lot of tech folks can be.

After that party, I headed a bit northwest to the Intel Day Zero IoT party, where like last year, they had a variety of demos and you could earn tokens for swag by listening to these demos, and even more tokens by talking shop with the Intel representatives at the booths.  This one is set up more like a dance party with loud music and flowing beer, and the people at the Intel party seem to be more in a social mood; rather than just standing around on their phones talking amongst their own coworkers, people are flowing around between so many demos that there are plenty of opportunities to meet cool people.  Now, the Netflix party had demos too, but maybe there were not enough or they weren't so compelling?

In any event, even from the experience of getting tickets for I/O on Tuesday before the event, I could already tell things were going to be better.  They had actual organization for the Uber & Lyft rides, and so I knew they had taken into account at least some of the lessons from last year.  In fact, here are my takes on how it's better:

  • Break-out sessions are overall in much larger rooms.  Last year, only one or two of the rooms were really big; the rest of the sessions were in small geodesic domes.  This year, those geodesic domes are reserved for demo rooms (which were mostly outdoors last year, with the exception of a few like Firebase and BigQuery), and all the conference rooms are large.  In fact, I think a couple rooms are even bigger than the biggest rooms last year.
  • The food actually tastes like it has flavor.  The downside to this is I was really looking forward to getting a "food cleansing" like I got last year, but with the improvement in quality, it doesn't feel like that's going to happen.
  • We're back to getting a lot of nice swag.
  • The transportation situation has improved a bunch, as they had well-planned routes for Uber and Lyft drivers to take.
  • There seems to be quite a bit more seating around the venue.
From what I can tell, the cost of these improvements seems to be that some of the demo areas seem to be a bit more squishy than they were last year.  However, previously the Office Hours and Design Reviews took place in half-open tents; this year, they are also in enclosed rooms.  There are still a bunch of demos to be seen; plenty on Firebase of course, but also Android Auto, Google Assistant, Android Things, and all the ways in which these platforms can be connected.

The key takeaway I have from all this talk though, including everything from the keynote to the breakout sessions, is:

Don't bother specializing in any one particular area.

As a developer who has always had a wide variety of interests in the field and written in a number of programming languages, I've seen where Google is trying to make things previously unfathomably difficult and basically impractical for any corporation to want to invest in (and for academics to only dream of) to be made possible.  At first, we saw Sundar Pichai talk about Google training machine learning models to come up with...other machine learning models.  Computers will now be testing in parallel what it takes data scientists months or possibly years to come up with on their own in series and only after lots of tedious model building and testing.  The other big announcement is that Kotlin is now being added to Android Studio in addition to Java.  And while Google promises that Java will still be a first-class language and supported heavily, it will soon become evident that those who know Kotlin will become much more efficient and effective at implementing Android code than those still thrashing through standard Java code.

Other notable events:


* Ellie Powers, Product Manager for Google Play developers, introduces Google Baby at Speechless.  As a result of my live-tweeting all of Speechless, she now follows me on Twitter.  Cool!

* Stacy was the headliner of a Women Android Developers panel in San Francisco Thursday night.

* "Make Your Android O-Face" will be the next big social media trend.

* And there's still a whole 'nother day of the conference left, so we'll see what transpires!

Thursday, May 11, 2017

Journey to a Fully Custom Pinball Machine - Part 1

The"maker bone" has bit me pretty hard since 2011 when I began working on LEDgoes/BriteBlox and won 3rd place the Apps for Metro Chicago hackathon with Owtsee/headonout.  And while I've worked on a mixture of side projects for profit and fun since, I can't help but note the urge to do more ridiculous things for myself just to say I did them -- not necessarily to make any sort of profit (in fact, most of my projects sink an enormous amount of time spent over several years before true completion), but for the notoriety.

The Actual Beginning Of This Post


There... Now that the part Google Plus will post as the headline is out of the way, it seems to me that my coworkers generally love me, and I love them too.  I am seen as quite the maker type inside my area, and have been invited to participate in events even in various groups I don't necessarily belong to because they like to "claim" me.  Often, these are external recruiting events, and I love exuding the ideals of our culture while getting a bit of exposure for my stuff, and it's even more fun to see the people I meet at these events working inside my office within the ensuing weeks or months.

It should be noted that the ROM hack of Tapper was done for the first such event.  I gave them a choice between me coming up with a clone of Microsoft's "Rodent's Revenge" (rethemed with elements from our business) or retheming the Tapper arcade game to show the logo of where we were rather than the Budweiser logo.  They picked the latter, thus that was born.  It even turned into a class I give periodically.

For the next event a bit over four months later, I sent along several ideas for things I could show.  They picked BriteBlox, despite that I pretty much showed that already along with Tapper.  I was a little less enthusiastic to simply show another LED light show, so I brainstormed about what else I could build around an LED light show.

Eureka...!

I was inspired, with only about a month to prepare, to combine this endeavor with something else on my agenda: making a custom pinball machine.  I'd already had in mind several things I wanted to experiment with on my very own game, and with not a lot of time left (read: time to write tons of game logic for different modes, not to mention wiring in all kinds of switches, drop targets, and toys), I actually opted to neglect the Bally Ms. Pac-Man cabinet I bought solely for the purpose of making my own full custom game (I even sanded all the paint off it a while back already) and go with a custom cabinet design that's only about 60% the size of a full commercial game.  This way, it wouldn't look so empty when I don't bother to populate the playfield with a whole lot of game elements, and it's also "easily" portable (you can pick it up by yourself without needing to tie it up, strap it to a dolly, take legs off, etc).

T minus One Month


After talking to someone particularly enthusiastic about my project, I knew I had to act fast.  I dabbled around with a Windows program called Visual Pinball to build and test my layout on the computer.  Version 10 has a fair number of idiosyncrasies, and although it's an open-source project, it requires a fancy version of Visual Studio that has some development libraries the free version doesn't come with.  So much for trying to make it the way I like it... Nevertheless, with enough perseverance, I managed to build myself a nice layout that seemed to play well, especially when I learned how to play "two-dimensional piano" in order to nudge the game (in the simulator) every which way to make the ball really go where I wanted it to.  (Is it wrong that I designed a game that requires nudging in order to be fun?  I feel like it adds to the skill of a well-rounded pinball player...)

Of course, any time I'm dealing with CAD software (even if it's a pinball simulator), I spend a whole lot of time with geometry.  Most of this was fairly simple measuring, but still tedious as I often liked to write down all the measurements to the ten-thousandth of an inch.  This is far more precision than I really needed for the CNC router, but I wanted to make every effort to ensure it would play in real life just like it did in the simulator.  This meant collecting precise alignments of the lanes, the round area in the back where the ball curves over onto the playfield after the initial shot, the pop bumper, the slingshot holes, rollover targets, general illumination... you get the idea.  Once it was all measured, I duplicated everything into VCarve (our program of choice for the CNC router), which took yet more time just from the sheer number of elements required for even a fairly simple playfield.  And this didn't even account for any "stencils" as to where mounting hardware for all the playfield accessories would go; I ended up attaching them by eye, hand, and feel later on.

What's new with this machine?


To summarize some of the enhancements I presented to the crowd at this recruiting event, and at the Texas Pinball Festival a couple weeks later:

  • High-end servo motor instead of complicated traditional flipper mechanisms
  • 3D-printed brackets as mounting hardware for many rollover switches & general illumination
  • Rollover targets consisting of inexpensive yet highly durable computer keyboard key switches rather than expensive specialty pinball switches that require constant cleaning and/or calibration
  • A DMD display consisting of a 24-panel BriteBlox LED matrix
As development went on, I also eliminated the need for a switch matrix by using an I2C port expander chip; more on that later.

Also, to increase our Intel street cred, I used the Intel Edison development board with the Arduino Breakout Kit, and fabricated my own driver board consisting of MOSFETs to drive the solenoids and pull-up resistors for every single switch.  No expensive P-ROC boards for me!  I'm doing this fully my way.  I know enough about single-board computers, development kits such as the Edison, and embedded C/C++ programming to just go about this myself... right?!

Stay tuned...


Usually I detail a project in a single blog post, thus many of my posts are really long.  Instead (because I'm crunched for time tonight anyway, and because this can easily be talked about in stages), I am going to write several posts on this project over the next few weeks, detailing the ins and outs of my journey.  And honestly, it has only been about three months since I started, thus the requisite number of years before I'm truly finished with something have nowhere near elapsed yet.  As such, there are still quite a few quirks with it (especially electrical gremlins) that I need to fix, and all that will be detailed here too.

I especially want to talk about my fights with MRAA and the Arduino Breakout Kit, and some of the "fun" involved with sensing multiple switches rapidly, from a technical standpoint anyway, and then of course get into softer things such as artwork and the game's logic and theme, and possibly a bit on fabricating the cabinet (which seemed to take a great deal of time).  Be sure to check in on Thursdays around this same time for future posts!

Thursday, April 27, 2017

My Journey With Implementing JPA

There comes a time in pretty much every programming project when you need to communicate with a database of some sort.  When doing this in Java, one choice is to manipulate DriverManagers or DataSources directly.  However, if you want to take advantage of POJOs to represent your data from the database, manipulating data as objects, you might be staring down the task of writing all sorts of ugly reflection code or a really long constructor to make this happen.  There is an alternative: the Java Persistence API.

Old news, buddy!


JPA is old-school, clocking in at over 10 years old!  (Jeez, I might as well bust out my IBM 5150.)  However, I did not feel like writing reflection like what was done on the last project, so I searched for an alternative.  JPA provides you a mechanism to add in details pertaining to object/relational metadata (ORM), and thus run all sorts of CRUD operations with minimal code, by offering convenience functions for these operations.  The objects you make persist the data in memory, just like a database would.  The Java Persistence Query Language is offered in order to help translate your objects into SQL, or you can use regular SQL.

JPA in and of itself is simply a framework, and there are many different providers of the advertised functionality and benefits.  Some of these choices include Hibernate, EclipseLink, and OpenJPA.  There’s also Spring’s JPA provider but since Spring is not part of my current project (much to my chagrin), it might not be so easy to just go and get it.  Also, OpenJPA doesn’t seem to be available in my available Maven repository, and I’m a Maven snob now; if I can’t get the dependency through a dependency manager, then forget it.  This pretty much leaves me the choice between Hibernate and EclipseLink.

Now, some people have given themselves fits with JPQL and how it is implemented by the various persistence provider they chose.  If you don’t want to use JPQL and/or are really good at SQL, then you can always write straight SQL to manipulate your data.  However, you’ll have to weigh using regular SQL with the possible drawbacks of not getting to use your nice POJOs.  Due to that article I just linked to, I ended up choosing EclipseLink and performing all my operations with SQL simply because I’m only doing SELECT operations.

The Gist Of a JPA Implementation


I use IntelliJ by JetBrains as my Java IDE.  In here, it is really easy to create a Java Maven project.  I am going to eschew detailing the basic steps of setting up a project and get straight into the code.

For starters, you need to get the correct Maven dependencies.  Then, build more or less a POJO to describe the contents of the table.  Open up the table description in your favorite SQL editor and copy it in or start writing it into your new class.  Normally, you should name the class the same as the table you wish to access.  Use the IDE to automatically generate the getters and setters once you have written in the variables.  Import the persistence library into your POJO class file in order to describe certain properties, such as the table name, which instance variable is the ID/primary key, and so on.

Build a persistence.xml file describing the means by which you will connect to the database, and which Java class will define which persistence unit.

Finally, make your EntityManagerFactory and EntityManager that will manage all the persisted data across all the instances of the POJOs you create by means of performing CRUD operations on your databases using functions from the EntityManager.

The Structure Of Everything


Here are the Maven dependencies you will need to import (if you wish to use EclipseLink, like I did):

<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>6.0.6</version>
</dependency>

<dependency>
    <groupId>javax.persistence</groupId>
    <artifactId>persistence-api</artifactId>
    <version>1.0.2</version>
</dependency>

<dependency>
    <groupId>org.eclipse.persistence</groupId>
    <artifactId>eclipselink</artifactId>
    <version>2.5.2</version>
</dependency>

You will also want to provide the maven-compiler-plugin as a <plugin> in your POM file with <source> and <target> configurations set to your JDK version if you’re having trouble using advanced syntax.

Here is a summary of my class:

package com.myproject.tests;

import javax.persistence.*;
import java.util.Date;

@Entity(name = "the_table_name_in_the_DB")
public class MyPojo {
    @Id
    private Long id;
    private String someOtherString;
    @Temporal(TemporalType.TIMESTAMP)
    private Date lastUpdated;
}

The @Entity annotation's name attribute is used when your table name is different than your class name.  It’s usually better to name them the same unless your table name is awful.  It happens…

Notice the @Id and @Temporal annotations too.  These are important; you always need a primary key (even if the underlying table doesn’t have one), and @Temporal is required for any Date or Calendar objects.

The next thing is the persistence.xml file, belonging at resources/META-INF/persistence.xml (either src/ or test/ is OK, depending on your context):

<?xml version="1.0"?>
<persistence xmlns="http://xmlns.jcp.org/xml/ns/persistence" version="2.1">
    <persistence-unit name=
"testJPA" transaction-type="RESOURCE_LOCAL">
        <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
        <class>com.myproject.MyPojo</class>
        <properties>
            <property name="javax.persistence.jdbc.url"
                      value="jdbc:mysql://mysqlOnRDS.rds.amazonaws.com/my_db?zeroDateTimeBehavior=convertToNull"/>
            <property name="javax.persistence.jdbc.driver"
                      value="java.sql.DriverManager"/>
        </properties>
    </persistence-unit>
</persistence>

In here, you specify the persistence-unit name (referred to by the EntityManagerFactory creator function earlier), the PersistenceProvider you are using (the PersistenceProvider class should always be implemented by the provider you chose), and your POJO class.  Then, specify other properties such as your JDBC URL, the driver you use for reading the database of your choice (here this is the MySQL driver), and possibly a username and password if you don’t care about keeping those in plaintext.

Note that the <property> names might change based on the particular persistence provider you are pursuing.  In this case, the name of javax.persistence.jdbc.url works for EclipseLink, but in OpenJDK, it would be openjpa.ConnectionURL .

Finally, I set the remaining important parameters and instantiate my entityManager with the following snippet.  The entityManager manages all the instances of my POJOs (objects) representing the (relational) data in my database table, and is responsible for giving us the ability to run queries.  Note that below, I'm running this as a JUnit test, thus the use of before() rather than main().

import javax.persistence.EntityManager;
import javax.persistence.EntityManagerFactory;
import javax.persistence.Persistence;
import javax.persistence.Query;

public class StepDefinitions {
    public EntityManager entityManager;

    @Before
    public void before() {
        Map<String, Object> configOverrides = new HashMap<>();
        configOverrides.put("javax.persistence.jdbc.user",
              System.getProperty("db.user"));
        configOverrides.put("javax.persistence.jdbc.password",
              System.getProperty("db.password"));
        EntityManagerFactory emfactory = Persistence.createEntityManagerFactory(
              "testJPA",
              configOverrides);
        entityManager = emfactory.createEntityManager();
        Query query = entityManager.createNativeQuery(
              "SELECT * FROM the_table_name_in_the_DB;",
              MyPojo.class);
        MyPojo firstRow = (MyPojo) query.getSingleResult();
    }
}

With System.getProperty(string), I can add the -D arguments (such as -Ddb.user=user) to build the application with the desired parameters on the command line, saving me from saving them in plaintext and/or checking them in anywhere.

You should also look at the documentation for entityManager to find out all the ways you can construct queries.  The one above takes a standard SQL string as an argument, but you can find ones that will work with JPQL.  The find(Class<T> entityClass, Object primaryKey) call is the simplest of them all, allowing you to find an object just by providing its primary key and your POJO class.

Battles I Fought


The persistence.xml file belongs in a specific place.  Since I am not running this application as a WAR (Web application) at all, and in fact this is simply a project that runs JUnit tests on existing servers, I learned it needs to go in src/test/resources/META-INF/persistence.xml .

The first time I tried to run my JPA code, it complained about

PersistenceException: No resource files named META-INF/services/javax.persistence.spi.PersistenceProvider were found. Please make sure that the persistence provider jar file is in your classpath.

Ultimately, I realized that while I had included the Persistence APIs themselves (javax.persistence.*), I omitted the actual persistence provider.  I resolved this by doing some quick research to pick between Hibernate, EclipseLink, and OpenJPA (though I would have used Spring’s one if I were making a Spring project).  Ultimately I added EclipseLink to my POM file.  It turns out I also needed to add the <provider> tag to my persistence.xml file with the name of the PersistenceProvider class: org.eclipse.persistence.jpa.PersistenceProvider  This one pertains to EclipseLink in particular.  Whichever JPA service you use, the provider class should always be named PersistenceProvider.

In IntelliJ, I also had to make liberal use of the “Reimport All Maven Projects” button.  It exists on the far right, folded up in the “Maven Projects” panel.  Unfold this panel, and then see the button that resembles a Refresh button.

Once I had this in place, Java gave me the following error:

javax.persistence.PersistenceException: No Persistence provider for EntityManager named testJPA:  The following providers:
org.eclipse.persistence.jpa.PersistenceProvider
Returned null to createEntityManagerFactory.

Since I was developing in IntelliJ with Maven, it would be surprising to me if the usual suggestions of fixing your CLASSPATH would actually help my problem.  In fact, by digging down, it was suggested that the root tag in persistence.xml (<persistence> itself) needed some attributes set.  To fix the error, I used this (as noted above):

<persistence xmlns="http://xmlns.jcp.org/xml/ns/persistence" version="2.1">

Now, I received a similar error upon adding these attributes in persistence.xml, but noticed I was making progress when closely scrutinizing the error message.  I saw that my class “does not specify a temporal type”, which “must be specified for persistent fields or properties of type java.util.Date and java.util.Calendar”.  Most tables will have timestamps of some sort in them as one or more fields, so for this, you will want to use the @Temporal annotation on any of your Date or Calendar objects in your POJO.  (Just be mindful to consider such things as daylight saving time when utilizing objects that do not specify a time zone.)

My next problem:

java.sql.SQLException: Zero date value prohibited

There are a couple ways to fix the problem where you have a timestamp consisting of all zeros.  Assuming you don’t have the ability (or care) to modify the data to NULL the all-zero timestamps inside the table itself, just add this to the end of your JDBC string:

jdbc:service://host:port/dbName?zeroDateTimeBehavior=convertToNull

After solving this problem, I ran across one more issue:

Exception Description: Entity class has no primary key specified. It should define either an @Id, @EmbeddedId or an @IdClass. If you have defined PK using any of these annotations then make sure that you do not have mixed access-type (both fields and properties annotated) in your entity class hierarchy.

In my case, the database table I inherited had no primary key.  It is not my concern to go in there and define a primary key at this time, so I was hoping to get away without defining it in the POJO.  If your database table does not have a primary key defined, it’s OK.  JPA does not care if you specify a primary key in your POJO that isn’t truly a primary key in your table, so just pick an instance variable representing a column that always has a unique value in it and add the @Id annotation to it.

Epilogue


After this was all said and done, I realized I would need more than just what one single table would give me in order to run my tests.  Data will have to come from joined tables, and that will be explored another day…

Sources


Override Configurations Loaded from XML (i.e. DON’T STORE PASSWORDS IN PLAINTEXT) - http://stackoverflow.com/questions/8836834/read-environment-variables-in-persistence-xml-file

Thursday, March 9, 2017

Appreciating Huge Light Marquees On Game Shows Of the Past

Recently, I dug up an old email where I was musing on the big marquee on an old television game show called The Magnificent Marble Machine.  It was a very fancy prop at the time, as most television shows of the era relied on art cards with big, bold letters that would be flipped, slid, or otherwise revealed by stagehands upon the emcee's verbal cue.

   k
Slide it, Earl! (Match Game) - Survey Says?! (Family Feud) -
Sources: YouTube, Game Show Utopia


This is about as fancy as it got for electronic graphics on game show props in the 1970s (Tic Tac Dough).  However, they never upgraded this board during the 1980s...
Source: Dailymotion

And a couple shots of the Magnificent Marble Machine game board in action.  Looks like a plain ol' marquee, but really an astonishing feat of engineering given normally chintzy television props, especially for its era...
Source: Gameshows Wikia

Cashing In On a Fad


Now, the Magnificent Marble Machine was a show produced in 1975 and 1976 by Heatter-Quigley Productions.  This "gem" only lasted about nine months, but you may know Heatter-Quigley for bringing us much more durable and enjoyable shows such as The Hollywood Squares.  The idea of the show was to capture and adapt for television the essence of a phenomenon that had been becoming very popular at the time: pinball.  You had The Who and Elton John singing Pinball Wizard before millions of fans and avid players starting in 1969, and in 1975, unless you ran across a Pong console, generally your only other option for cheap entertainment out on location was pinball.  And games from 1974 and 1975 such as Sky Jump, Top Score, Wizard!, and Captain Fantastic were stealing quarters from players of all ages, and still fondly remembered to this day based on their ratings at the Internet Pinball Database (I can vouch for Top Score personally as well).  However, the pinball machine on MMM (brought out for the bonus round) featured a fun factor more in line with watching someone play Atari's Hercules game, only even bigger and more sluggish.

Generally, pinball machines of this era were all electromechanical in operation, involving liberal use of solenoid coils not just to actuate active elements on the playfield but also serving to operate physical latches for memory and game status.  Lots of springs and mechanical linkages would be involved, and complicated beasts called "score motors" would advance the score in the manner required and pulse score reels to rotate at 36 degrees through every digit, 0 through 9.  Generally, you would not find so much as a resistor in these games in terms of electronic components, but only a transformer to step down 120V from the wall to 24V for game components.

However, 1975 was a big year for microcontrollers, as the MOS 6502 was first released to the public (this chip was used in all sorts of devices including pinball machines for decades to come).  Pinball was soon to come of age in the solid-state realm as well, with both Bally (using Intel's 4004 chip) and Allied Leisure producing pinball machines in 1975 with such new and improved electronics.  However, Atari also began work in 1975 on its VCS home console, and we all know what home consoles did to pinball and arcades in general...

Making a Light Marquee The Old Way


I hope you'll take a moment with me to appreciate the level of engineering and expense that went into creating the scrolling clue board seen during the game on MMM.  Nowadays, this could be easily accomplished with a matrix of high-intensity LEDs and very simple microcontrollers to display the letters; you should know I successfully Kickstarted such a thing back in 2013.  But by 1975, LEDs were so small and low in intensity that they were used on little more than expensive electronic test equipment as status indicators, and on cutting-edge calculators, the numbers on which were so small that lenses were placed above each digit to enhance readability.  Clearly these early LEDs were not useful for consumption by far-away viewers like the TV cameras filming the show (which still used small vacuum tubes instead of modern CCD chips), or people viewing a marquee outside a theater, or etc., and were not an option for people building scrolling marquees.  With LEDs out of the question, people still used regular incandescent light bulbs.

For the digital logic that controls the lights, there were very few programmable microprocessors at the time.  Intel released the first ever CPU for consumer purchase, the 4004, in 1971.  The MOS 6502 was not on sale by the time MMM began to air, and Motorola's 6800 chip which came out the year prior was still selling for $175 in 1975 dollars.  Of course, the now-standard x86 line of chips found in PCs did not exist, nor did PCs themselves (unless you want to call the Altair 8800 hobbyist kit a "PC"), and none of these primitive processors were designed to run at speeds above 2 MHz.  Chances are that only electrical engineers working for large computing firms at the time (like HP, Digital, and Texas Instruments) were using these brand-new CPUs in any applications; they were vastly more complex than anything people dealt with in the past, and so most electrical engineers throughout the 1970s still built digital logic out of discrete components such as the 7400-series integrated circuits, or by actually using transistors themselves to build the logic from scratch.  (Heck, pretty much all the major pinball manufacturers were still using these original microprocessors along with 74xx logic for extra features 20 years later!)  To make a scrolling LED board out of 7400-series ICs would require lots of different chips (such as registers, multiplexers, and simple Boolean operators) and lots of wires.  But above all, each incandescent light would require its own special relay so it could be driven by the digital logic.

While most basic logic circuits such as the 7400-series ICs operate at 5 volts of direct current, light bulbs typically operate at a much higher voltage -- up to 120 volts, and then it's alternating current, not direct.  Unlike nowadays (since we have good LEDs that run at 5 volts DC), the voltage generated by the digital logic circuit when a light should be on could not be used to directly power that light.  So, the output from the digital logic circuit would be fed into relays that would provide the correct power for each light at the appropriate time.   There must be one relay for each light.  Once again, I re-emphasize the beastly amount of wiring that must have gone into that sucker.

And what might all this have cost?  Well besides the engineer's time, the parts would have been quite pricey, and certainly far more expensive than they are now, even after inflation.  Based on my analysis, you'd need at least one 74LS373 chip per column of lights on the board just to keep the lights on if you didn't buy latching relays instead (after you've already used a bunch more chips just to discover who's supposed to be turned on), and did you see how many columns there are?  While I don't have any data for 1975 prices, prices for the mil-spec version of various 7400-series ICs were $18 to $29 per chip in 1965.  In that year, the average family income was only $6900; prices like that would keep these chips out of most hobbyists' hands, but by the 1970s, they were appearing in many microcomputing kits for hobbyists--these kits were still as expensive as, say, a nice stereo at the time.  (Nowadays, you're stupid if you're an electrical engineer and can't figure out where to get some of these for free.)  And while I also don't have any historical price data on relays, they're still priced at between $1 and $100 apiece nowadays, depending on the complexity, materials, and how many volts & amps it puts out.  Probably the least expensive components would have been the lights themselves. :-P  So from an engineering standpoint, it's sad that board didn't get used on a show that ran for a very long time, but hopefully it found a good home somewhere else...

...Maybe on Family Feud?  (Feud premiered about 3 months after the last new MMM episode aired...)
Source: Game Show Garbage

Epilogue


Apologies for all the "original research" in here... If I could dig up my Internet history from 10 years ago or so, I would cite the sources for the figures I quoted, such as the prices of the electronic components.  However, you have access to Google if you are reading this, and some of my original sources have gone offline and have been replaced with other sources in the meantime I'm sure, so you might learn something about a particular niche you're interested in if you try to corroborate my figures.