How to Look Under the Hood at Javascript Code

I'm finally taking the long overdue step of learning Javascript. Part of the process of learning language is to figure out what it is doing at a far lower level then the luxurious heights at which we get to program. Plus it's just damn interesting.

In the Node (using v10.14.2) usage description there is an option --v8-options. Run Node with this to see a long list of options to give directly to V8, the Javascript engine running under the hood of Node.

There are a few options in here that will get us a look at the inner workings of the Javascript code we write.

--print-code
--print-bytecode

--print-code prints the code out in x64 assembly, I think.

--print-bytecode prints the intermediate bytecode.

For even a simple program like hello world there are a few pages of bootstrapping code that also gets printed out. Your functions are put under a label that looks like this: 

[generated bytecode for function: myadd]

Use that to your advantage to find your code.

Good Luck!

-Victor F.

Silicon Valley Code Camp 2018

This weekend I attended Silicon Valley Code Camp. Code Camp is a conference on its 12th year held in San Jose California and put on by volunteers. I’ve known about it for many years (I found the earliest email I got from them is from 2009), but this was my first year of attendance.

In this post I give quick play by play of my weekend, with summaries, impressions and/or takeaways from each of the talks I attended.

Saturday I arrived late and had no problem getting my pass as I had registered early. I arrived late to my first talk. It was about IoT with Edge. I’m very disappointed I missed as much as I did. I was able to glean how Edge devices and routers interact to communicate with the cloud. How twins of the device status are mirrored on the cloud and what role hubs perform when connection to the cloud is severed. It seems that it runs on raspberry pi, I was not aware of that. 

The second talk was on C++ server API’s. The speaker was really entertaining and explained things well. He went on a few tangents which took a lot of his time, but they were entertaining so I forgive him. However, he couldn’t finish the talk on time so a few things were skipped over. I’m really not criticizing him for this. I don’t think that not getting the full talk made my experience on Saturday any less vaLuable. More than anything this talk was more a discussion on best practices when beginning new projects.

The third talk I went to was on java and Kubernetes. This one was tough. I do not know enough about docker to have gotten as much as I’d like from this. I got a general idea of workflow, of setup, of Java through docker with Kubernetes within IntelliJ.

Next was a talk on Recursion and Dynamic programming for technical interviews. This was really just a talk. It represented recursion and dynamic programming with simplified language as opposed to any detailed implementation or code. Dynamic programming fit into the talk really smoothly. Again, it used the same simple explanation technique as used for recursion. What’s more it seemed very natural to explain DP directly after explaining recursion as he had built up the concepts in such a way that the two example problems were nearly identical.

The final talk was not technical. It was about human learning techniques. Worth the time and part of the reason I’m writing this. The speaker was really good and covered some things that hold back learning, techniques students and educators could use (like a learning journal) and some myths.

Sunday was more laid back: fewer people, less prepared speakers, for lack of a better description, less popular topics.

I started by going to an intro to mongoDB. My take from the talk was that It sounds like a great way to get away from SQL tables and a carefully planned DB before implementation aka. prototyping. 

For the rest of most of Sunday I attended a series of talks by 3 gentlemen. The series was ostensibly about creating drivers for android. That’s not what it was. It was implement Android’s Binder Inter-process communication as a linux device drivers.

The first talk was the best for anyone who went for an education on android. It covered concepts of binder which would help any Android programmer to better understand and better utilize the technology.

The second in the series was an introductory tutorial on writing kernel mods for linux and a bit on the Android Linux kernel.

The third talk was the curve ball. Where the speaker showed his implementation of Binder on an Ubuntu AWS machine. A little bit of a letdown but overall a really excellent series but for the expectations set. Now looking at the schedule I can see the signs. 

Finally a talk on interfacing with C from Lua and Ruby. in all directions: Lua to C, C to Lua, Ruby to C, and C to Ruby. It’s apparently really easy to call C libraries in Ruby. The speaker spent more time than was needed on summarizing each language. I don’t believe anyone actually attended the talk which didn’t know one of the languages and so the subject of actually interfacing seemed to not get enough attention while the majority of the talk was used to educate everyone on the properties of Lua and Ruby which weren’t necessarily relevant to interfacing with C.

Food and drink were provided in the morning, at lunch each day with occasional snacks set out, and ice cream in the afternoon on Sunday. There were raffled prizes donated by the event’s sponsors. It was well worth the money paid. In fact it was worth far more than the money paid. I’m really kicking myself for 9 years of stupidity for not attending.

- Victor F.

REST API WEEK! App a Day 22: Reddit Images

https://github.com/victorman/RedditImagesAndroid



I'm not sure if this one is really accessing an API, technically. Though it does request subreddits in JSON in order to display thumbnails of images which doesn't require any authentication.

REST API WEEK! App a Day 21: Goodreads Authors

https://github.com/victorman/GoodreadsFavoritesAndroid



Classes Used: Service, AbstractThreadedSyncAdapter, XmlPullParser, ContentProvider, ContentResolver SQLiteOpenHelper, Handler, ContentObserver.

I've always wanted to play with the Goodreads API. So here's my first attempt. Responses are in XML only, unfortunately. This makes a request for the books (reviews) in my favorites shelf and lists the authors. Very simple in theory. I was going to do more but I ran out of time.

I finally made some templates files for a SQLite Database, but without any of the provider's URI constants. Just copy the gist code below into a file template.

REST API WEEK! App a Day 20: Facebook Likes

https://github.com/victorman/FacebookLikesAndroid



Uses Classes: FacebookSdk, LoginButton, FacebookCallback, AsyncTask, Thread, BaseAdapter, GraphRequest, JSONObject, JSONArray.

This uses the Facebook Graph API and SDK to display the first page of the user's likes.

REST API WEEK! App a Day 19: Weather Map

https://github.com/victorman/WeatherMapAndroid



Classes Used: ContentProvider, ContentResolver, Service, AbstractThreadedSyncAdapter, GoogleMap, Handler

I think I need to learn a lot in regards to what is possible using data that is already out there. So I'm going to make this REST API week. I'll use different API's in all of my dailies.
This one uses openweathermap.org. Using it's cities in cycle feature it grabs current temperatures for 10 cities near your current GPS location and displays the markers on the map.

App a Day 18: Todo with DatePicker

https://github.com/victorman/TodoAndroid



Classes Used: DatePicker, Preference, PreferenceActivity, CheckBoxPreference, SharedPreferences, Preference Manager, OnPreferenceChangeListener, OnPreferenceClickListener

I fought with this one for a good while. I'll say if you're starting a new project it's probably a good idea to store dates as string. If you are storing them as integer's just remember that SQLite assumes your time is in the format epoch time in SECONDs. Not milliseconds, even though an integer in SQLite is 64 bits, same as java's long. Okay just remember that.

App a Day 16: Coursera Android Concurrency Assignment 1

Day 16 is unconventional, I'm going through Coursera's online class called: "Programming Mobile Services for Android Handheld Systems: Concurrency." This is the first assignment from that course. The assignment is to implement a couple of predefined Threads and Runnables and use a java semaphore. The UI and the app structure already existed. Here's the unfinished source.

App a Day 15: OneTableApp with Parse Login

https://github.com/victorman/OneTableAndroid/tree/login



As when you're doing anything simple in android simply combining yesterday's app with the previous OneTableApp using parse was 'anything other than simple. More build.gradle problems (remove "compile fileTree(dir: 'libs', include: ['*.jar'])"). Parse's signUpInBackground wasn't even running the SignUpCallback's done method (Restart your emulator). And somehow one of my AppCompatActivity wasn't using an AppCompat theme (check all of your styles.xml files, all of them).

App a Day 14: Simple Login w/ Parse

https://github.com/victorman/SimpleLogin/tree/parse



Uses Classes: ParseUser, ParseObject, Intent.

This app demonstrates a simple log in, log out, and sign up UI for parse. I started with the Login template from android studio, but I think things would have been simpler if I had just started from scratch and followed the parse guide.

App a Day 13: Todo

https://github.com/victorman/TodoAndroid



Uses Classes: ListActivity, SQLiteOpenHelper, SQLiteDatabase, CursorAdapter, PreferenceActivity

I finally decided to make this staple app way later than I should have. There really isn't anything new in this app just reenforcing things I've already learned. I did make some effort to at least write down steps to implement the common patterns in this app that I would use again.

• Local SQLiteDatabase for persistent storage
1. Define one or more Contract classes. You could do one Contract for a number of tables or one contract for every table. It's up to you how you organize it. You just need to know where things are.
2. Define a static Entry class, which implements BaseColumns, for every table you will use in your database.
3. Extend SQLiteOpenHelper and override onCreate and onUpgrade methods and define a constructor. The onCreate method will call db.execSQL on a string containing your create table query.
4. Define static CRUD methods for each action you'll be taking on the database. Make these methods of the Contract class so you can access them from anywhere (Activity, Adapter, etc.)
• ListView with CursorAdapter
1. Create a ListView with android:id="@android/id:list" in your main activities layout.
2. Create a layout file layout/list_item_layout.xml.
3. Extend CursorAdapter in a new class defining a constructor and overriding the newView and bindView methods. In new view inflate R.layout.list_item_layout and return it.
4. Optionally, create a static private class called ViewHolder. In here define public field variables for each of the views in your list item's layout. Define a constructor that requires a view as a parameter and using that view's findViewById method assign your field variables to these views for easy access later. In your overridden newView method you instantiate a ViewHolder and call setTag on the view which you return. When you implement bindView call getTag on the view and cast it to the ViewHolder type to access the view identifiers.

App a Day 12: InsideArea

https://github.com/victorman/InsideAreaAndroid



Uses Classes: LocationListener, GoogleMap, Polygon, LatLng.

Today's app returns to google maps to determine if the gps location is in a given boundary. It implements a ray casting algorithm to determine if a point is within a polygon. I would have expected this to be built into the google maps API's library, but all of the solutions I found to do this suggest there is not. However, implementing the algorithm isn't very complex.

App a Day 11: Checklist

https://github.com/victorman/ChecklistAndroid



Classes Used: AsyncTask, ArrayAdapter, ListActivity.

This one was much more problematic than I had anticipated. I will probably revisit this one soon.

App a Day 10: Camera

https://github.com/victorman/CameraAndroid




Uses Classes: Camera, SurfaceView, SurfaceHolder.Callback, CameraPreview.

I hadn't intended to take a week off, but I stayed with my parents before my sisters wedding and it was pretty difficult to not get involved in wedding preparations.

So I have a lot of running to do. But here's another simple app. I simply followed this guide omitting the video stuff and filling it in with a fix.

App a Day 9: OneTable using ContentProvider

https://github.com/victorman/OneTableAndroid/tree/provider



Classes Used: ContentProvider, Uri.

Once again, refactoring the very first day's app. this time using a ContentProvider. The way I understand it a ContentProvider is an added layer of abstraction onto the app's persistent storage. So the rest of my app has no clue that SQLite is the underlying database. A big help in this one was the Sunshine app from Udacity's Android course.

App a Day 8: Map

https://github.com/victorman/MapperAndroid



Classes Used: FragmentActivity, SupportMapFragment, GoogleMap, LocationListener, LocationManager, Location.

This took all of like 10 minutes to make and was directly following this tutorial. That's encouraging, I think I'll make more map apps now.

App A Day 7: Diet Plan

https://github.com/victorman/DietPlanAndroid



Classes Used: Intent, ListActivity, SQLiteDatabase, Cursor, SimpleCursorAdapter, AlertDialog, SQLiteOpenHelper.

My first practical app. It is a diet plan for a workout program. All the information is hard coded and inserted into the database when first created. This one uses three tables and joins two. It simply uses a ListActivity and SimpleCursorAdapter. When an item is clicked it opens a second activity called IngredientsActivity. This is also a ListActivity, the only difference is items need to be long clicked and then a dialog is opened with alternate foods. Look at this activity at your own risk, it's a little messy, but I'm glad it worked out.

App a Day 6: OneTable with Parse

https://github.com/victorman/OneTableAndroid/tree/parse



Classes Used: Parse, ParseObject, ParseQueryAdapter, AlertDialog, ListView

Identical to the app I made on day 1 except with a parse back end instead of a SQLiteDatabase. I was a little frustrated by things at times especially because a friend was singing it's praises, how it was so easy to use, painless to set up, etc.. It wasn't. First I was impeded by gradle problems and then a not so intuitive local data store. I could only EITHER get it to work in local data or remote. So I chose remote, Eventually deciding what was required to have both simultaneously was an unnecessary extra complex problem.

This tutorial should get anyone wanting to do the same on the right track

App a Day 5: Timer

https://github.com/victorman/TimerAndroid



Classes Used: Timer, TimerTask, Calendar, Handler.

I needed a really simple app for this day and this was much simpler than I thought it ever would be. This straightforward tutorial shows all the basics. The app simply starts a timer which runs a task. The timer runs in the background, but then sends a runnable back to the UI thread every second to update the timer display with the current count. In this one I didn't use a layout xml file because it was complicating things for when I wanted to swap out the buttons. I suppose better way would just be to have the button use one onClickListener a which would determine if I'm starting or stopping, but I didn't think of that then.

App a Day 4: Dice

https://github.com/victorman/DiceAndroid



Classes used: GridView, BaseAdapter, PreferenceActivity, Intent.

This one was a hair ripper. This isn't even true to my original concept and I came up with it for day 2. As you know I worked out only ONE die. However it's close enough.

It's basically what you get from this guide on GridViews, plus the roll button and a PreferencesActivity so I can alter the number of dice.

To get a PreferencesActivity started via the action menu bar I needed a menu layout and a preferences screen layout. I'll leave out the menu xml since it's auto-generated every time you start an android project.


And that other part that auto-generated by Android Studio every time I start a project? That's where the intent goes to open SettingsActivity


Go to the repo and look at the settings activity. It's simply an activity which overrides onCreate which is going to take the xml file above and make a preference screen with it. But it is also an OnPreferenceChangeListener so when things get changed it tells itself (really) to update the preference summary to the new value. I'll use the listener again in the adapter.

Finally I need an adapter. Adapters are objects that manage data or objects for views that display repetitive structured information, so in this case a GridView. The GridView displays some data in the same way over and over again in specific pattern but the data changes with each grid cell. The adapter is going to make sure the right data get to the right cell.

This adapter is an extension of BaseAdapter. Basically the GridView, as it attempts to draw itself, tells the adapter, "Give me what I need to draw for cell 0." By calling the adapter's getView method and passing the position number to it. I override the getView method so it returns an ImageView with the correct configuration and image. In this case an ImageView displaying the face of a die.

Another important part for this implementation is the array that the adapter uses called mArray. This is not a standard feature of BaseAdapter, but necessary for this case. I made the adapter into a listener for preference changes. Every time the preference for dice count is changed I reset the array to one of the new size filled with all -1.

Finally back in the MainActivity class whenever you roll the dice, change the array in adapter to the new number. I do this by making it public but you could also use getItem if you're using a reference to an actual object. When the number's changed call mAdapter.notifyDataSetChanged and that will call getView again and redraw the views, thus setting them to the correct face image.

I hope this was educational. Good night.