Where Were These Resources Weeks Ago?

After learning about IndexedDB in the GrowWithGoogle Mobile Web course, I’m enhancing my big personal project to create a local backup of the MySQL database using IndexedDB with PHP and jQuery

If only I’d been aware of this “Google Search” thing a month or two ago … 😉

From MySQL to IndexedDB
https://stackoverflow.com/questions/44638999/from-mysql-to-indexeddb

Also mentions PouchDB and CouchDB
https://stackoverflow.com/questions/37921898/synchronization-between-mysql-and-indexeddb

Synchronization between mysql and IndexedDB
https://codeforgeek.com/2014/11/sync-app-mysql-indexeddb/

SyncedDB repo
https://github.com/paldepind/synceddb

Client-side database solutions: IndexedDB (says “teh codez”)
https://www.corporate3design.com/blog/24

Create Your Own To-Do App with HTML5 and IndexedDB
http://blog.teamtreehouse.com/create-your-own-to-do-app-with-html5-and-indexeddb

Offline Add, Edit, Delete Data in HTML5 IndexedDB
https://www.mindstick.com/Articles/1535/offline-add-edit-delete-data-in-html5-indexeddb

Advertisements

Breaking Stuff Is Good

In preparation for integrating what I’ve learned in the Grow With Google Challenge Mobile Web course into my rockin’ app, I did some spring cleaning. Getting rid of all the files with duplicate-ish names like handle_albums2, handle_albums3, handle_albums4, handle_albums_test, and so on.

I broke the app.

I’m sure I was saving those for a reason but I was also sure I was being a hoarder.

In my attempts to fix it, I realized there was a much more efficient way to organize everything that would fix some ongoing issues. So now I’m doing that.

Progress is good because I am so dying to start the Data Visualization part of the app which is, ultimately, it’s whole purpose. I’ve been dying to put stats up using the data I’ve gathered so far but it would be with graphs made in Excel and … that’s cheating … I want to use D3 … so … no wasting time with stats and trivia that could be spent improving and nurturing the app.

Meanwhile, I am on my biggest David Bowie kick since the 80s. My top five artists change their order and slots a lot but the top five generally stays the same. David Bowie is always there but it’s been a long time since he was the #1 top rotation in my music collection. He wasn’t even #1 when he died. I was too busy crying and did not want to be one of those “I love David Bowie!” people jumping on the bandwagon just because he just died. Yeah, I’m that pretentious prick. I know. I’m sorry.

Finally listening to Blackstar. The videos were so creepy they scared the crap out of me and I couldn’t listen to the title track or Lazarus. And since I couldn’t listen to those, I just didn’t listen to the rest of the album.

The Next Day, however, is easily in my top three Bowie albums. It’s been #1 on my Bowie list since it came out.

Promises for Five-Year-Olds

This is a work in progress …

I’m happily going through the Grow with Google Challenge Scholarship: Mobile Web course at Udacity. We use javascript promises throughout which I kinda sorta basically understood the basic concept of. I didn’t completely get it but I knew we’d cover it later and everyone in the forums raved about Udacity’s standalone JavaScript Promises course so I planned on taking that after finishing Mobile Web. I wasn’t worried. I understood the structure just enough to put things together and pass the quizzes (eventually) by basing my answers on examples we were given.

I got the How (they worked structurally) but not the What (they were doing) or the Why (would I use them versus callbacks and/or Event Listeners).

I got to the Promises part of Mobile Web and it still didn’t really make sense to me. So I stepped out and started the JavaScript Promises course. That was great for a few minutes then I was lost again. I can’t tell you how many times in both courses I’d said, “Wait, wait … what?!”

This isn’t a criticism of those courses and sections. My learning style is just incompatible with certain teaching styles. I don’t do well when people say things like, “A promise is a promise that returns a promise—get it?”

No. No sir or ma’am, I don’t.

I posted a question in the forums, “ELI5 How Promises Work” and gave a couple examples of how I thought they worked based on the only thing I really knew about them – they were an ES6 replacement for callbacks … right?

I didn’t wait for answers because I was scared I’d get buried under other terminology and crap that meant nothing to me and would only confuse me more. I grabbed my Google Search box by the throat like Jacob wrestling with God and shouted, “I’m not letting go until you explain promises to me!”

The MDN documentation had me for just a moment or two as well but also lost me.

For the life of me, I couldn’t understand how Promises were related to Callbacks when (I thought) one was replacing the other and it seems to me callbacks were doing all the work anyway. And … eventListeners, right?

The ridiculously awesome Jake Archibald wrote a legendary thingy on Promises that finally started me down the road to understanding. First of all, I realized callbacks aren’t asynchronous … they’re merely blocking, meaning … well, I love Jake’s explanation (which I’ve paraphrased a wee bit):

Sneezing is a blocking function. All current activity must be suspended for the duration of the sneeze. You don’t want to write code that’s sneezy.

That made perfect sense to me. Callbacks aren’t asynchronous … nothing is happening and I’ll do other stuff while it’s happening and when it’s done it will let me know … everything stops while I do this thing and when I’m done doing this thing everything starts up again. Got it.

Jake also said,

“Promises are a bit like eventListeners except … we’re less interested in the exact time something becomes available than reacting to the outcome.”

Okay. That makes sense. Jake also gave a couple examples that, at first, smacked me into “Wait, what?” land again but I took a deep breath and re-read it … and felt I had a loose grasp on it all. I’ve been there before, though, and those cookies of understanding can crumble and fall through your grasp right before your eyes.

Sadly, Jake soon lost me.

As it turns out, Promises are pretty freakin’ easy … until people try explaining them. Eventually, I found two resources that changed all that. The two most valuable things I dug up:

Don’t just read the chosen answers at each. I read through all the comments and answers and replies and they are both a treasure trove.

Even just the titles made me feel much better about my confusion.

Aviv Cohn, the author of Aren’t Promises Just Callbacks? gave this ridiculously short and simple of a callback in his question and all of a sudden I finally understood callbacks so I made some real progress even before reading the replies! Cohn then explains promises in his own words,

“A Promise is an object that represents a value which might not yet exist [emphasis mine]. You can set callbacks on it, which will be invoked when the value is ready to be read.”

That sentence immediately made sweet love to things Jake had said and gave birth to some more understanding on my part. Cohn then gave the promise version of his callback code and concluded by asking,

Is there actually a real difference? The difference seems to be purely syntactical.

The first response started to beat the crap out of me with,

“Yes: callbacks are just [insert crap I couldn’t understand]. Promises are [more crap I didn’t understand] … a composable mechanism to chain operations on values.” [emphasis mine]

Oh. Okay. I don’t know what “composable” means (more on that later) but the rest of the bit in italics made more stuff click into place. Another answer blessed me with,

It is fair to say promises are just syntactic sugar. Everything you can do with promises you can do with callbacks … The deep reason why promises are often better is that they’re more composeable, which roughly means that combining multiple promises “just works,” while combining multiple callbacks often doesn’t.

First of all, thank you for defining “composeable.” Second, this person then goes on to drop a whole bunch of other magical wisdom explaining the difference and how they work and why — in freaking English — including working with values and errors and this:

For the example you gave of a single callback versus a single promise, it’s true there’s no significant difference. It’s when you have a zillion callbacks versus a zillion promises that the promise-based code tends to look much nicer.

My 5-Year Plan

Jim Carrey once wrote himself a check for $20 million.

In five years, I will have helped at least 1 million people get their dream jobs.

I’m going to create the fastest-growing, most obviously effective training and coaching program in the world.

Those who work with me will be unable to imagine working anywhere else. We will have a culture unsurpassed by 99.99% of other organizations.

To Do:

  • Finish Grow With Google Scholarship Challenge course
  • Complete the Mobile Web nanodegree program with a GWG scholarship
  • Complete the Google News Data thing [update this] program
  • Complete that other Data News [update this] program

Just to show I can and because I can, create kickass eLearning using HTML5, JavaScript, and After Effects that surpasses anything and everything I ever made with Flash.

To Do in 2018:

  • Complete every After Effects course at Lynda.com
  • Launch Coding After 40 and Coding After 50

Time Management & Priorities

Should green squares and StackOverflow reputation be my highest priority?

Sometimes, they are. Not that you can tell by looking at my StackOverflow reputation.

My FreeCodeCamp timeline is completely empty because I started focusing on actual development with personal projects. I haven’t abandoned it. I just haven’t returned for quite a while.

freeCodeCamp.png

A return to learning (the Grow With Google challenge course), however, has had a similar effect on my GitHub “personal projects” timeline which had become, IMHO, rather respectable.

green.png

Having said all of that, I’ve shown great improvement on the timeline only God sees for commits to my wife and children. And I still feel guilty. Like, someday, I’ll have this great job that I say is for my family (what we might call the Walter White Work Ethic) but by the time I get it, they’ll have moved out and I spent all my time preparing to be a good father some day instead of … being a good father. So, while far from perfect, I am mindful of that. I hate how hard it is to tear myself away from work (not my sill day job — real work on stuff like this) to spend time with them. Ugh.

What I do find is that the more time I spend with them the happier I am, the less anxious I am to improve my quality of life, the less I feel compelled to escape my day job, and the less painful that job feels. So, there’s that.

Update: After the initial learning in the GWG course, I started applying that knowledge and …

apply.png

… while STILL keeping my policy of never saying no twice in a row. What does that mean? I give myself one “I can’t right now, I’m working” but the next time one of my children asks to play — no matter what — I give all of us the gift of playing together.