Category Archives: Programming

Apple Developer Program: Room For Improvement

I’ve wanted to learn to make iOS Apps for some time, so I finally bit the bullet and bought a Mac Mini, downloaded Xcode, and started programming. I’m getting to the point where I want to deploy and test my app on my own iPhone (rather than run in a simulator), but in order to do that, you have to join the Apple Developer Program so you can appropriately sign and deploy your App to real iPhone and iPad hardware. And boy, what a pain joining this program is!

I should qualify this statement…I’ve joined the Apple Developer Program before as an individual. Everything went through ok then, but i never got around to actually building an App. This time, however, I decided to F.O.C.U.S – Follow One Course Until Success – and to actually build an App this time. And this time, I decided to join the Apple Developer Program as a Corporate Entity; you know, with designs of becoming a Billion Dollar Unicorn. Apple gets funny with Corporate Developer Registrations, seemingly. They require that you have a DUNS Number. Ok, whatever. I’m used to bureaucracy. I went and got me a DUNS Number. But for some reason, it took weeks (in reality, months) to associate a DUNS number with my Company in Apple land. Dun and Bradstreet told me to wait a few weeks, after updating some key email and phone number information, before trying to enroll in the Apple Developer Program again. So I waited…and waited…and I’m still waiting…

After waiting entirely too long, I tried to enroll again. This time, Apple complained that my credit card was being rejected. Really? Ok, so I tried another credit card. Rejected again. Really???? I logged in to both credit card accounts. Sure enough, successful charges from Apple on both for $99, but for some reason, Apple would still not let me enroll in their program:

What would Steve Jobs do?

At this point, I am quite flustrated. Of course I will press on, because I am committed to this project and to learning iOS development. But I never had this much problem getting an Android App out into the Google Play Store…I expect much more of Apple.  This process should have been absolutely thoughtless and painless.  But it’s a good reminder of how difficult and tenuous it is to build a company on top of another company’s technology.

EDIT (2/16/2017): I called Apple today and was unable to resolve the technical problem behind registering online, so I registered for the Developer Program over the phone this afternoon.  Part of my urgency in getting this registration done was because I wanted a shot at attending WWDC2017 this year.  Registration for WWDC2017 is by random selection to members of the Developer Program in good standing as of 2/16/2017 at 0530am PST.  I registered online the evening of 2/15/2017, but it failed due to technical problems with the Apple website (my credit cards are fine).  So I’m hoping I can still figure out a way to get in good standing for possible selection to WWDC2017.

Building A Startup On AWS

Let’s Dance

Building on the knowledge learned from my previous two blog posts on my following of the Wild Rydes AWS Serverless Computing Tutorials, ( Wild Rydes Part I and Part Deux), I decided to put some of that information to use in my own work at

I’ve been working on some mobile apps and a back-end platform supporting my trans-Atlantic Ocean Rowing attempt last year with my girlfriend, Cindy. I’d like to turn some of the things I’ve developed thus far into a Software as a Service (SaaS) for other people to easily use on similar adventures. To that end, I wanted to quickly create a responsive website to put out some information about my future offerings, including the ability to allow interested parties to contact me by providing their email address and a contact message in a simple contact form.

Know Your Limitations. Build On the Shoulders of Giants

I know I do not have great web design skills. Web Design is just not my focus. But I needed to create a nice looking website for my startup landing page. What to do? I did some quick searches and found lots of free Bootstrap templates I could use for my purposes. Over the course of an afternoon I grabbed a free Bootstrap Template that I liked, cut-in some of my own images, and modified the html to create the menus and sections I wanted in my landing page. I brought in some of the JavaScript from the Wild Rydes tutorial I was working through to connect my Contact Form to my DynamoDB database running in my AWS Account. After I had a look-and-feel I was going for, and the functionality was working ok for the Contact Form, it was simply a matter of uploading my web site assets to my S3 bucket:

> aws s3 sync . s3://

Stop Daddy

I had previously registered my Domain Name ( with GoDaddy last year. Now I wanted to move the DNS Registrar to AWS. This turned out to be very easy. Once I followed the documented steps to move a domain to AWS, I only had to add an A Record to point to the domain to my S3 Bucket containing website artifacts. I will point this A Record to a CloudFront endpoint soon.

Lipstick On A Pig

Now that the landing page is up, there is a mountain of work to do. The next step is to get email working for my domain using AWS SES so I can use that domain email to register as an organization in the Apple iOS Developer Program.

AWS Serverless Computing Example: Wild Rydes Part Deux

WildRydes Admin Interface

In my last blog post, I mentioned how I was working my way through @jpignata‘s excellent tutorial on GitHub on how to work with AWS Lambda Services, API Gateway, etc.  I work through the tutorial when I have a few minutes to spare and am finding it quite enjoyable.  AWS Lambda Services and the API Gateway are pretty fun and interesting to work with.

In Lab 3 of the tutorial we create an Admin Interface to allow authenticated users the ability to view the email addresses that have been added to the DynamoDB database.  Admin Users are authenticated by the Admin Interface against a Cognito User Pool.  This lab was pretty straight-forward as I did not fat-finger as any mistakes this time.  However, I did take note of the following:

API Gateway URL Notes:

  • Make sure to ‘Deploy API’ after you make changes to your API Gateway.  Many times I thought my configuration updates simply weren’t correct, when in fact I had simply forgotten to deploy the updates to ‘prod’.
  • Simply adding ‘Authorizers’ on your API Gateway is not sufficient for protecting the URL endpoint.  You have to also add the Authorizer to the Method Request ‘Authorization’ of the URL endpoint.  I found that my API endpoints were not protected until I remembered to do this step:

Lambda CI/CD Pipelines

As I am slowly working up to doing something more substantial with Lambda Services, I am curious how one might integrate Lambda Serverless Code into a CI/CD Pipeline.  It seems you can use Gulp/Grunt with the gulp-awslambda plugin ( to accomplish this.  I need to to try this out.

My Admin screen is available on CloudFront, but you can’t log in.

My API Gateway Endpoint is publicly available as well, but it should be protected against unauthenticated users:

What a great tutorial!!  One more Lab to finish and I’ll hopefully be off building something real…

Some Randomness : ‘The Black Bear’

My girlfriend and I have been watching ‘Black Mirror’ on Netflix occasionally.  Last night, we watched the ‘White Bear’ episode, which freaked me out, as most episodes do.  But, it also made me think of one of my favorite Bagpipe Tunes, ‘The Black Bear’.  Hear some renditions to make your cubicle-bound blood start pumping:

Paaaaaaaassssssss. In. Revieeeeeeeeeewwwwwwwwwwwwwwwwww!!!!!

AWS Serveless Computing Example: Wild Rydes Part I

I’ve been working through a tutorial I started in a session I took at AWS re:Invent 2016.  I did not finish the tutorial in class so I started working on it again after getting home from the conference.  The tutorial is on GitHub if you care to follow along.

Admittedly, I’m not the sharpest knife in the drawer(but I am made of the hardest, most persistent steel…they call me, ‘Blue Steel’ – said in my best Ben Stiller voice).  It took me a while to figure out why I could not get the AWS Javascript SDK to allow unauthorized users, vis-a-vis AWS Cognito, to access my DynamoDB Email Table.  Here are some errors and things I learned troubleshooting this:

The latest Firefox browser seems to give better clues about why things are not working in the Developer Console than Google Chrome.  Using Google Chrome, I kept seeing an error like, “Missing Credentials In Config”, and was really confused what exactly that meant.  I was following the tutorial exactly, as far as I could tell, so I could not discern whether this error was from a code change I made or an AWS configuration problem?  Then I looked at my website in Firefox, using the Firefox Developer Console, and could see a little bit better what was going on.

Here’s my main error as seen in the Google Chrome Developer Console:

And here’s the same error as reported by Firefox Developer Console:

Ahh!  So a ‘ResourceNotFoundException’ is being thrown.  Now I could see that my Javascript code probably wasn’t the problem and that my Cognito/IAM Role Configuration might be the culprit.

After further investigation..a day (or so) later…I discovered a simple typo in my DynamoDB Table Name:

The table name should have been ‘Wildrydes_Emails’.  Seriously?!?!  Yes, I’m an idiot (but one made of ‘Blue Steel’…).  Once that was corrected, I was finally able to get my unauthenticated Cognito Role to access my DynamoDB Table.

There is still work to be done in this tutorial, and I’ll blog about any issues I overcome as I encounter them.  My work is being hosted in my AWS account on Cloudfront, so feel free to check it out and submit your email to my DynamoDB database.  Let’s get this startup rolling!

'Out of the Box' Rubik

Infrastructure As Code

I recently read this article and listened to the 2015 AWS re:Invent session on the same.  This discussion really resonated with me.  I’m excited to try to automate everything, including infrastructure deployments, in my future development projects.  I like the idea of using automated testing frameworks, such as serverspec, for testing infrastructure deployments.

My three big take-aways from the video:

  1. If it’s not automated, it’s not done.
  2. If it moves, measure it.
  3. if its’ not monitored, it doesn’t exist.

My Path to AWS Certified Solution Architect – Associate

On December 1st, 2016, I took and passed the AWS Certified Solutions Architect – Associate Exam.  I took the exam at the AWS re:Invent Conference in Las Vegas, and by ‘passed’, I mean by the skin of my teeth!  But to me, passing is all that matters and I achieved that objective.  Here are some notes on how I prepared for this certification exam:

  • I tried to use AWS Services as much as possible.  I signed up for a free for one year account and started deploying some small applications I had written to EC2.  Initially, I ran MySQL on one of my EC2 instances, but when I discovered RDS, I learned that RDS is an easier and more cost effective approach to using an RDBMS in the cloud.  Aurora and DynamoDB are some other excellent options for cloud-based databases.
  • I bought the Official Study Guide for this certification and started studying it and working through the exercises in the book about two months prior to my exam.  As I am now done with this book, I am happy to mail it the first request for free as long as you agree to pay for shipping.  I have marked my copy up pretty good, however, and I’ve circled all of the answers to the practice test questions in ink.
  • I paid $20 to take the AWS Practice Exam.  I failed it with a 50% score and almost ended up re-scheduling the real exam.  I decided, however, to double-down on my studying and to stick my original plan.  This is one gamble of mine that actually paid off.
  • I attended the 2016 AWS re:Invent Conference in Las Vegas and participated in the Monday Night Hackathon.  Here I quickly learned how to deploy REST services on AWS Lambda using the API Gateway service.  I also learned a bit more about DynamoDB in the process.  The Hackathon helped to focus my understanding of some services, and the re:Invent Conference helped to broaden my understanding of many others.
  • I took my certification exam on Wednesday Night of the conference at 8pm in the Venetian Hotel.  I thought I would be the only one taking an exam at that time of night, but there were at least 15 other folks in the examination room with me.

Here are some of my associated exam expenses along the way:

  • The Official Study Guide on $57
  • Scheduling the Certification Exam: $150
  • Practice Exam: $20
  • AWS re:Invent 2016 Conference: $1600
  • Travel and Lodging at Las Vegas (me, girlfriend and kids): $750
  • Estimated Exam Focused Time Investment: 2 months
  • Estimated Total Investment: $2,577

AWS re:Invent Conference

So was my investment in this certification worth it?  One thing I learned at the re:Invent conference in Vegas is that if you want to win big, you have to bet big.  I think this investmAWS Solutions Architect Associate Certification Study Guideent was a pretty big bet as far as certifications and technical focus are concerned.  I don’t think attending the re:Invent conference was necessary in passing the certification exam, however, but I do think it was necessary in trying to accurately gauge the viability of the AWS Cloud Platform in the coming years.  Participating in the Hackathon was a great way to get focused on approaches to deploying solutions to the AWS Cloud in a team environment.  AWS re:InventAttending the AWS re:Invent conference helped me to broaden my perception of the sheer breadth of AWS Cloud offerings, not to mention the insight I received in learning about some of the innovative ways companies are using AWS Cloud now.  I witnessed over 30,000 conference participants, from all over the world, attending sessions from 8am to 8pm non-stop, learning as much as they could about the AWS platform.  I, too, drank the cool-aid and truly believe AWS Cloud is a secure, cost effective, highly elastic, high performance platform for all types of software applications.  And I don’t see any other cloud company as a close competitor to Amazon right now, nor may we ever.  Amazon has built their Cloud Platform from lessons learned being the largest E-Commerce Platform in the world.  I feel like I’ve made a safe bet.

AWS re:Play Party

Financial costs aside, the re:Play Party at the end of the AWS conference was truly amazing!  There were drinks (lots of drinks), t-shirts, amazing, amazing food, retro video games, mechanical bull riding, foosball, etc. etc. Time to re:Play I’m sure there was even more stuff, I just couldn’t take it all in.  Then there was the headline performance by DJ Martin Garrix, which was radical.  I took my girlfriend to the party and we had an amazing time.  It was an amazing week in Las Vegas, which ended with a quick family jaunt to the Grand Canyon, but I’ll save that for another blog post.


Getting MEAN: A Java Developer’s Perspective

I intimidate many people because I’m so pretty. Others might say I’m pretty ugly. But when I had the chance to get MEAN too, I jumped at it. In this context, MEAN is an acronym for the technology stack consisting of: MongoDB, Express, AngularJS and NodeJS. I wanted to briefly document some of my recent experiences and take-aways in working with this technology stack, so here are my thoughts.

For most of my programming career now, I’ve been working with mostly Enterprise Java. I started teaching myself Java in the mid-nineties from an O’Reilly book and from the start found the language very intuitive to understand (then). For a number of years now, however, I’ve been thinking that full-stack JavaScript is the way to go for Enterprise Software Development (and other applications as well). So when I had the opportunity to work on a short project using MEAN I was quite glad to get some hands-on experience with it.

First of all, when working with MEAN, you are essentially using the JavaScript language at all layers of application development, from the front-end to the middle-tier to the back-end data store. Theoretically, this should make the learning curve considerably smaller when working across layers, and should also make JavaScript Developers equally interchangeable across layers. The reality, however, is not quite that, but it’s close.

‘M’ Is For MongoDB

MongoDB is a NoSQL database used for storing JSON Documents. MongoDB is very easy to install and run, especially on Linux-based systems. You can run JavaScript in the database; you can even write MapReduce programs in JavaScript and run them on the database. But the main advantage of using MongoDB in this technology stack is the ability to easily store and retrieve JSON documents without have to apply JSON structure to your data after pulling it out of the database. This makes it easier to ship JSON formatted data directly to your front-end without having to mess with RDBMS tables and SQL… and even DBA’s for that matter (‘…can you PLEASE create a table for me!’). Wait, I don’t say ‘please’ anymore because I’m MEAN.

‘E’ Is For Express

Express is a dream to work with. It’s very simple and intuitive to use and takes no time at all to go from knowing nothing to creating fairly complex JSON REST Web Services. We connected Express to our MongoDB instance using Mongoose, which is so simple even I could configure it. Simple is good, right?

‘A’ Is For AngularJS

I found working in Angular 1.x fairly difficult to understand. The associated documentation is not all that well written and generally not very helpful. I feel like the framework is a bit over-engineered. I have not worked with Angular 2.x yet, so perhaps things have improved. Nevertheless, many, many organizations have invested heavily in Angular, so I’m sure I must be missing something, and without a doubt AngularJS is better than working with Java Server Faces (JSF) or Struts. Nevertheless, I might actually try ReactJS as the front-end framework next time as several co-workers have strongly recommended it.

‘N’ Is For NodeJS

NodeJS is the server-side JavaScript middleware that ran our Express JSON REST Services. Working with NodeJS requires that you get used to writing asynchronous code, but once you get the hang of that it’s quite fun and easy to use. From a Java Developer’s perspective, working with NodeJS is so much more efficient than having to compile and package Java Code into a WAR or EAR before deploying it to a JEE Container, like Tomcat or JBoss or Websphere or Weblogic. In Java land, that process seems to take years sometimes. When using NodeJS and a code monitor like nodemon, you simply forget about about the code deploy process and start to take for granted that your code changes are instantly available for testing on your local server. What?!?!

The Node Package Manager (npm) makes installing and managing modules very easy as well.

Fast Development, Fast Deployment

As mentioned, using code watch tools like nodemon, or even grunt or gulp serve-up local code changes in real-time. That speeds up development time significantly. Moreover, your mocha, chai, karma, etc. test scripts are invoked automatically each time you make a code change, so feedback on whether your build is broken or not is instant and continuous. Once integrated with an efficient Continuous Integration/Continuous Delivery (CI/CD) Pipeline, code commits to Git can be automatically built, tested and pushed-out to a running server in your environment of choice. Of course you can do the same in Java, but I bet that MEAN Developers can develop twice the functionality, if not more, than Java Developers in the same amount of time.

In business, speed kills when your MEAN (and pretty).

Collecting Energy Price Data

I’m not sure why exactly, but I am particularly interested in fluctuating energy costs, particularly the costs associated with putting gas in my car.  I remember that Regular Unleaded Gas (or Petrol for you Europeans) was $.99 a gallon when I started driving around 1985 in the arid South West of San Antonio, TX.  Of course gas is more expensive today, but I’m often surprised how relatively cheap gas prices remain for a gallon of Regular Unleaded.  I feel fairly confident that it’s just a matter of time before all energy costs, Regular Unleaded Gas not excluded, will rapidly increase.  Energy is a limited resource yet the global population continues to grow.

Anyway, I wrote a python script (adapted from a Perl script I wrote to do the same a few years ago) to grab the current National Average Price for Regular Unleaded Gas.  My script runs automatically each morning to collect the daily price of Regular Unleaded Gas and dumps it into a MySQL database I have running on AWS.

Here’s a graph snapshot of the data I’ve collected so far (click to enlarge).

Graph the GasHere’s the table of the data I’ve collected so far:

| id | rec_create_dt | price_date | price | year | month | day |
| 1 | 2016-07-25 01:53:08 | 2016-07-24 | $2.165 | 2016 | 7 | 24 |
| 2 | 2016-07-25 09:46:16 | 2016-07-25 | $2.161 | 2016 | 7 | 25 |
| 7 | 2016-07-26 11:11:50 | 2016-07-26 | $2.154 | 2016 | 7 | 26 |
| 8 | 2016-07-27 06:00:16 | 2016-07-27 | $2.154 | 2016 | 7 | 27 |
| 9 | 2016-07-28 06:00:22 | 2016-07-28 | $2.148 | 2016 | 7 | 28 |
| 10 | 2016-07-29 06:00:21 | 2016-07-29 | $2.142 | 2016 | 7 | 29 |
| 11 | 2016-07-30 06:00:22 | 2016-07-30 | $2.139 | 2016 | 7 | 30 |
| 12 | 2016-07-31 09:30:22 | 2016-07-31 | $2.135 | 2016 | 7 | 31 |
| 13 | 2016-08-01 09:30:22 | 2016-08-01 | $2.132 | 2016 | 8 | 1 |
| 14 | 2016-08-02 09:30:23 | 2016-08-02 | $2.126 | 2016 | 8 | 2 |
| 15 | 2016-08-03 09:30:23 | 2016-08-03 | $2.120 | 2016 | 8 | 3 |
| 16 | 2016-08-04 09:30:23 | 2016-08-04 | $2.116 | 2016 | 8 | 4 |
| 17 | 2016-08-05 09:30:23 | 2016-08-05 | $2.120 | 2016 | 8 | 5 |
| 18 | 2016-08-06 09:30:23 | 2016-08-06 | $2.124 | 2016 | 8 | 6 |
| 19 | 2016-08-07 09:30:24 | 2016-08-07 | $2.123 | 2016 | 8 | 7 |
| 20 | 2016-08-08 09:30:23 | 2016-08-08 | $2.123 | 2016 | 8 | 8 |
| 21 | 2016-08-09 09:30:24 | 2016-08-09 | $2.124 | 2016 | 8 | 9 |
| 22 | 2016-08-10 09:30:24 | 2016-08-10 | $2.127 | 2016 | 8 | 10 |
| 23 | 2016-08-11 09:30:25 | 2016-08-11 | $2.130 | 2016 | 8 | 11 |
| 24 | 2016-08-12 09:30:25 | 2016-08-12 | $2.129 | 2016 | 8 | 12 |
| 25 | 2016-08-13 09:30:21 | 2016-08-13 | $2.127 | 2016 | 8 | 13 |
| 26 | 2016-08-14 09:30:26 | 2016-08-14 | $2.125 | 2016 | 8 | 14 |
| 27 | 2016-08-15 09:30:26 | 2016-08-15 | $2.124 | 2016 | 8 | 15 |
| 28 | 2016-08-16 09:30:26 | 2016-08-16 | $2.125 | 2016 | 8 | 16 |
| 29 | 2016-08-17 09:30:27 | 2016-08-17 | $2.132 | 2016 | 8 | 17 |
| 30 | 2016-08-18 09:30:26 | 2016-08-18 | $2.135 | 2016 | 8 | 18 |
| 31 | 2016-08-19 09:30:27 | 2016-08-19 | $2.141 | 2016 | 8 | 19 |
| 32 | 2016-08-20 09:30:23 | 2016-08-20 | $2.152 | 2016 | 8 | 20 |
| 33 | 2016-08-21 09:30:28 | 2016-08-21 | $2.158 | 2016 | 8 | 21 |

The Lean Startup

Angular versus ReactLinux versus WindowsJava versus Python?


The important technical question is whether or not your software is something people are willing to pay for.  If no one is buying your software product, then your Technology Stack is irrelevant.  People don’t typically buy a software product because it’s written in C++ or NodeJS.  People buy software products because it solves a problem, whether that problem is boredom, financial, security or something else.  This is one reason why I really enjoyed reading Eric Ries’ book, ‘The Lean Startup’.

This book is packed with wisdom focused on how to discover the value of your entrepreneurial software idea through ‘Build, Measure and Learn’ iterative development cycles.  Eric’s Lean Startup ideas borrow heavily from the Japanese product development processes at Toyota and beyond.

Here are some things I took away from this book and the Lean Startup Movement in general:

  • Everyone can and should be an entrepreneur.  It’s ok to be an entrepreneur inside of a well-established organization; in fact, it’s beneficial.
  • Lack of innovation is death in business.  [I want to read ‘The Innovator’s Dilemma‘ in reference to this point.]
  • Build, Measure, Learn feedback cycles should be used to collect data from your target market.  Ask the hard questions of how you are doing from your customers.
  • If your product fails to grow, consider the concept of a ‘Pivot‘ to find greater acceptance and use of your product.
  • Four key questions to keep asking:
    • Do consumers recognize that they have the problem you are trying to solve?
    • If there was a solution, would they buy it?
    • Would they buy it from us?
    • Can we build a solution for that problem?
  • Genchi Gembutsu – Go see for yourself.  Trust but verify.
  • Build your MVP quickly to see if you are heading in the right direction.
  • Experiment.  A/B Testing.  Customer testing.  Collect Data.
  • Taiichi Ohno and the Five Why’s
    • At the root of every seemingly technical problem is a human mistake.
    • Five Whys helps to get to the root of the technical problem.
  • Time to Build not important.  Time to Measure not important. Time to Learn not important.  What’s important is the time it takes to get through the whole process.

“Our society needs the creativity and vision of entrepreneurs more than ever.  In fact, it is precisely because these are such precious resources that we cannot afford to waste them.” Eric Ries, ‘The Lean Startup’, pg. 278




Building Great Software Teams

‘The whole is greater than the sum of it’s parts.’  — Aristotle

Where I went to High School, the members of the Football Team often wore T-Shirts that said, ‘There’s No I In Team’.  At the time, I thought it was strange how obvious this was and that maybe the football team was just feeling proud of their newly found spelling skills.  ha ha.  Now that I am older and a bit wiser, I am starting to better understand the profundity of this statement: “There’s no I in Team”.

Over the course of my professional career as a Software Engineer, I have had the pleasure of working in some amazing Software Engineering Teams…and some not-so amazing ones.  In the amazing teams, I often wished we could stay together, forever, or at least the duration of our careers, so we could continue working hard and having fun building great things.  But being part of a great team never seems to last very long.  Engineers get bored, Companies get sold, go public, people get hired away…  The stability of great software teams just never seems to last very long.  It’s really too bad, because great software is built by great teams, not individuals.  It’s just like the sport of football.

One of my new favorite TV shows is ‘Ballers‘, with The Rock.  I’m struck by how similar the recruiting process is for key technical talent and football players, albeit on a much smaller scale of grandeur for most software engineers.  I wish Company X would recruit me for $10 million over 3 years…But all this focus on the individual talent would seem to detract from the most important thing a Company or Football Franchise is trying to build: Great Teams.  A $10 million dollar Running Back may gel great with the players in Miami, and not gel so well with the players in New Orleans, for example.  Building the right team is hard and often just happens out of dumb luck.

What if companies/organizations hired teams instead of individuals; or, what if software engineers who enjoyed working together and gelled well marketed themselves as a Team to Corporate Recruiters instead of as individuals?  I still haven’t figured out how that would work logistically or practically, but it’s an interesting idea I think.