Programming on your phone

May 19, 2016

I have figured out how to program on an Android phone or tablet. Using Google Cloud Platform and a couple of Android apps, I have a cloud development box, and I can pull up a command line and edit files locally in my Android device.

I’m going to describe the method I use. You can, of course, use different apps that do the same thing. This is just my method of implementation.

Setup up Google cloud platform. See https://cloud.google.com/compute/docs/quickstart

Create an instance named dev-instance. I use a small preemptable insurance to save on money. You can use a larger instance (but not a smaller one). You can choose to make it preemptable or not. Preemptable is nice because if you accidently leave it running, it won’t stay up more than 24 hours.

Install the Android Google Cloud Console app. Also install JuiceSSH and the paid version of DroidEdit.

In JuiceSSH, go to Connections, slide to Identities, and click the plus to create a new identity. In the Nickname fields, enter ‘dev-instance identity’. Under username, type your Google user ID. Press Set next to Private Key. Go to Generate. Change Key Format to RSA. Hit OK to generate the key (this may take a while). Then press the checkmark in the upper right hand corner to save the identity.

When the identity is created, long press it and select Export Public Key. Select Copy to Clipboard.

Go into Google Cloud Console. Go to Resources then to VM Instances. You should see your instance, dev-instance. Click it and select Ssh from the the dots menu in the upper right hand corner. Select Connect via SSH. This will open a console window to your instance. Type

 cat >> ~/.ssh/authorized_keys

Be sure there are TWO greater than symbols. Then long press the screen and select Paste. This should paste your private key from JuiceSSH into the window. Press the console window to turn on the extra keyboard. Press Ctrl then ‘d’. Type ‘logout’. We’ll be connecting to the console from JuiceSSH from now on. Press OK to close your session.

You should be on the screen for dev-instance. Scroll to the bottom and expand Compute Engine Details. Long press the entry for External IP and select Copy. Also, write this address down, because we’ll need it later.

Go to JuiceSSH. Slide to Connections and press the plus sign to add a new connection. Under Nickname, type ‘dev instance’. Long press the space for Address and press Paste. This should paste the external IP. Make sure Identity shows ‘dev instance identity’. Hit the check mark in the upper right hand corner to create the connection.

Press the connection to test it. When it asks you to trust the connection, hit OK. You should get a command prompt. Type ‘logout”.

Swipe back to Identities. Long press ‘dev instance identity’. Select Export Private Key, then Copy to Clipboard.

Open DroidEdit (this must be the paid version). Press the drive looking icon to get a file menu. Press New. Long press the empty document and select Paste to paste the private key. Now select Save As from the file menu. Press local, then navigate to /storage/emulated/0. Press the folder plus icon and create a folder named ‘.ssh’ (make sure the folder name starts with a dot). Name the file ‘id_rsa’ and press create.

Go to Settings, then Remote Files. Scroll to the bottom and press Global Private Key Path. Enter ‘/storage/emulated/0/.ssh/id_rsa’. Hit OK. Press Add Remote Server. Server Name should be ‘dev instance’. For Server Address, enter the IP address you wrote down earlier (or go look it up again). For username, enter your Google ID. Check Use Global Private Key. Press Test to check it. If it asks for a passphrase then you’ve done something wrong. Press Save and exit the settings.

And you’re done! You can now program on your phone or tablet. To open files, use DroidEdit. To get a command line, use JuiceSSH. You have to set up the box with your development environment, but once you do, you can program wherever you are, if you just have a phone or tablet and an internet connection.

Austin Code Dojo

May 8, 2012

Anouncing
The All-New, Re-Imagined
Austin Code Dojo
Austin Code Dojo

This Dojo is a place for various forms of programming practice, just as a martial arts dojo is a place for various forms of martial arts practices.  We will have a beginners kata for new coders, students, and managers who used to code; and a more advanced kata, if there’s interest.  We also welcome all other forms of cooperative programming practice.  Solve a programming challenge, hack on an open source project, share some code you’re working on, or just talk about programming stuff in a friendly, unstructured atmosphere.  The point is group practice of all sorts.
Read the rest of this entry »

Pablo’s Fiesta 2011 Notes

October 4, 2011

I went to Pablo’s Fiesta this past weekend.  It was an amazing conference with lots of energy and lots of things to learn.  Here aare some of my notes.  I maay go back and clean them up, or expand something, or just leave them s is.  For now, tho, here they are in raw form:

Read the rest of this entry »

How do you tell a master craftsman?

January 17, 2011

I asked my 12-year old son today what it means to be a craftsman and a master craftsman (of any profession). Then we went on to discuss how you can tell that someone is a master craftsman. I find his answer illuminating:

  1. They should be able to talk their craft and, if you’re not a master yourself, they will lose you and go over your head and talk about things you don’t understand. This was from a child’s view, but I interpret it as “They must be able to talk up their craft”.
  2. They should be able to create a sample on demand. He was thinking about small crafts when he mentioned it, but when we talked about bigger things (like skyscrapers), we decided a small test problem would suffice.
  3. (and this I think is the most important one) They should show you their previous work. They should be able to say, “Look, I created these high quality things in the past, so I can create high quality things for you in the future.”

The book Software Craftsmanship book mentions that to be a master, you must have a masterpiece. To claim that you’re a master, you must be able to show some really good work. So in our discussion of how do you tell a master craftsman, the answer is simple: look at their work.

When you hire an artist (painter, photographer, sculptor, etc.), you look at their portfolio. All artists have one, and it’s how they get work. So, if we’re craftsman, we should have portfolios. Résumés are similar to portfolios, but a) they don’t emphasize actual completed works enough, and b) they’re dry and boring. So maybe we need to start making multimedia portfolios to highlight our abilities as a craftsman. I picture web sites with screen shots, customer testimonials, sample code, links to your blog and other sites, and links to free software or other non-work projects you’ve created.

The key here is, if you want to convince someone that you’re a master craftsman, show them your work and your masterpieces.

Ron “Ziroby” Romero
http://www.ziroby.com (which has some portfolio elements, but needs to talk about my actual for-pay work)

[cross-posted to the Software Craftmanship list at http://groups.google.com/group/software_craftsmanship/browse_thread/thread/a9a03d96ff298a26 ]

Austin Style Code Dojo

August 22, 2010

Here in Austin, Texas, we’ve just started weekly dojos. Our dojo style is similar to Randoori, but without pairing (instead of pairs, we’re all one set).  In Randoori terms, we use something similar to Ping Pong.

The flow goes like this: One of the coders writes a failing test.  Lately we’ve discussed the proper API in detail during this step.  I think we’re trying to learn the wisdom of proper test structure.

Once the test fails, that person sits down, and someone else goes to the keyboard.  That person solves the test, does any refactoring, and writes a failing test.  Then they pass the keyboard.

It continues like that, with each person doing “Fix it.  Refactor. Break it.  Pass Keyboard”.

We’ve been working in very small groups of about 3-5.  In that size, everyone sees what’s going on and gets a chance to drive.  We don’t have a projector, which isn’t too bad since the groups are small. (But if someone wants to lend us one, it could be useful.)

We allow discussions and suggestions and comments at any time (not just on a green bar), but the rule is “the person at the keyboard is supreme dictator”.  They can choose to ignore everyone else, or go with whatever suggestion they choose.

We’re still working out the bumps, but we seem to have a good system going.  If you’re in Austin and have a Monday evening free, come join us at Genuine Joe’s Coffeehouse from 8 – 10 pm.

What comes next after TDD katas?

August 16, 2010

What comes next after TDD katas?  UI Testing?  Mocks?  Design Patterns?

I’ve been doing TDD katas and dojos for a while now, and I think I’ve learned the first lesson.  I know the cadence of “break it, fix it, refactor”.  I understand Baby Steps and The Simplest Thing That Could Possible Work.  I get the importance of test choice in guiding the evolution of design.

So what’s my next lesson?  What’s the next thing the katas and dojos can teach me?  Maybe I need to figure out how to test UIs, and how to make testable UIs. The Humble Dialog Box may provide insight and direction there.  A coworker suggested that I need to learn mocks, maybe JMock or RhinoMocks.  I think there’s a kata in there somewhere.  I’ve tried the Publish/Subscribe example from JMock, but that feels too simple, a Hello World of JMock.  What’s a more complex kata that needs mocks to solve?  Or maybe I need to find a way to incorporate Design Patterns into my solutions.  So far I’ve evolved very simple designs, so they haven’t needed Design Patterns.

So what’s the next lesson to learn from code katas?  I know there’s a lesson in there somewhere, and I feel like I’m on the verge of learning it.  What is that lesson?

What Matters in a Dojo?

July 18, 2010

We in the Austin Code Dojo have been doing weekly dojos for four weeks now, in Genuine Joe Coffeehouse in North Austin, Texas. We’ve been learning a lot in these sessions.  Here are some of my notes.  These mostly talk about what matters in a dojo.  What are the important things we’re doing and why are we doing things this way?

Read the rest of this entry »

Cyborg Poker Night

July 12, 2010

Cyborg games: a human and a computer working together to play a game better than either could alone.  There are Cyborg Chess leagues out there, but how about having a Cyborg Poker Night?

Read the rest of this entry »

Video of Hello World Kata

July 6, 2010

I just created a video of the Hello World kata.  A code kata is an instance of deliberate practice in computer programming.  The video walks through the kata in Eclipse, with a narration.

http://www.youtube.com/watch?v=oXYw-ppevA4

Moon Phase Sprints

June 21, 2010

In Wicca there is a concept of the magical power of the moon. Each moon phase has different power, and different magickal workings should be done during each phase.  We can apply this to Agile sprints to make Moon Phase Sprints.  The sprints would be one moon cycle long (29 – 30 days).  The waxing half would be used for the generative, or creative, tasks, and the waning moon would be an opportunity for polishing, testing/fixing, and retrospective.  This gives an internal structure to each sprint, and lets the work follow a natural rhythm.

Read the rest of this entry »


Follow

Get every new post delivered to your Inbox.