Sunday, January 4, 2015

Day 5 - 30 Day Learning Challenge

Try Blockly!!!  I tried it when it first came out and thought well, it has some potential but needs work.  Well they did a lot of work since I last looked at it.

As far as a tool for allowing students to learn about programming using tile scripts while providing a way to switch to Javascript (and I believe also Python, but need to double check that).

I haven't tried building projects with it yet, only played the games and watched some videos.  I recommend the following two videos:
First for educators check out: 

CS4HS Blockly with Ellen Spertus


Second for a great tutorial on how to create your own blocks:

The second is rather well done and the type of supporting documentation that students and teachers need.

Plus it also does Logo see the Turtle example and it can be run Offline!!!

Cheers,
Stephen
P.S. I am having too much fun (mostly with Blockly and thinking about learning/teaching/doing programming.  Oh I also made some more progress at Code School

Day 4 - 30 Day Learning Challenge

AngularJS vs Etoys 
(as a tool for younger people to work very deeply by programming and building stuff)

First this is not a fair comparison, as Etoys was designed for this purpose and Angularjs was not.  Yet I understand the desire to have a tool to that can be used for exploring ideas, communicating and expressing themselves.  I also understand the request to have tool that can be used in a browser.

First I will start with AngularJS’s advantages:
  1. It has the support of Google
  2. There is a large community of people who use AngularJS and an even larger community who know JavaScript
  3. There are many resources on the Web for learning about AngularJS and very good support groups willing to help beginners
  4. There are lots of code examples one can learn from and play with on Plunker and JSfiddle.


The challenges of AngularJS:
  1. You have to spend a lot of time learning about AngularJS and how to do things in AngularJS which takes away from the time spent  on learning/expressing/exploring.
  2. It is built around the Web in particular the DOM.  Ie: you are restricted to what the DOM can do.  Okay not completely true you can blow a hole in the DOM and using SVG or Canvas but the libraries available to do things here (think D3 et al) are very specific and require high learning curves.
  3. While the learning curve when compared to other Web Frameworks is not quite as steep, there is a steep learning curve for students especially if they do not have a lot of programming experience.
  4. It is a text based language (as opposed to a tile based one) which means syntactical errors are easy to make and take time and cognitive load to understand and correct.


The advantages of Etoys:
  1. It was designed for construction and learning by students
  2. It supports tile based scripting and lets you switch to text based.
  3. It lets you directly manipulate objects and extend their functionality.
  4. The community to support learners is responsive and helpful.
  5. There are some good educational resources for students and teachers to explore.


The challenges of Etoys:
  1. There is no large organization or funding supporting Etoys.
  2. The community while supportive and helpful is not large.
  3. Etoys currently does not run in browsers or on tablet or phones (Yes, I know it can and there are projects which show its possible, but there is no “supported” fully functional and fast enough version that does so for all “modern” browsers).
  4. Etoys is not as popular as AngularJS
  5. JavaScript is more popular than Squeak (and thus has a larger base of people who could potentially support teachers and students).



So all this aside perhaps the best tests are how easy is it to:
  1. For a teacher to build an educational tool for students
  2. For a student to create a form of expression
  3. For a student to explore certain ideas


Now to quote Seymour Papert “It’s hard to think about thinking without thinking about something.”  So I will try to think about some things and how they could be done in AngularJS and Etoys (and perhaps some other ways of doing things).  So at some point I will try and think about "something" more concrete.


Ideas and suggestions welcome for “what to build”.

Cheers,
Stephen
P.S. Also made some progress at Code School but poor internet connectivity has limited my time on the computer and increased the time spent with family :)

Friday, January 2, 2015

Day 3 - 30 Day Challenge

Well coding while driving is not easy and since we spent most of the day driving my coding was limited to a few minutes just before I crashed at the hotel.

I did think about coding though while driving which was challenging.  It forced me to a higher level rather than specific code, I thought about the general problem and how I would approach it.  My goal is to take a number of concrete examples of data sources (csv and JSON for now) and visualizations (table and graph) and "connect" those together.  Then see what general patterns I can determine/code from that.  I did manage a brief period to figure out how to walk through a javascript object to get the Keys I would need to tie a JSON feed to a visualization.  My thought is to inspect the data to determine the fields/keys that are available to connect to either a table (will look at using smart table for first attempt, since some folks I know are using that) and also either HighCharts and/or D3.

I plan on creating the data structures, directives, and controllers to allow me to connect the data source to a visualization.  Then the next step after that will be to think about and perhaps try to implement some simple user interfaces that allow a lively like drag and drop connection between the data-source and visualizations.

Cheers,
Stephen

Thursday, January 1, 2015

Day 2 - 30 Day Challenge

I completed lesson 3 from Shaping Up With Angularjs.

Since we will be driving to Florida over the next two days I will be thinking about code rather than writing it.  I plan to think about how I can implement something like the lively demo using Angular.  In particular how to "connect" a data source to a visualization and allow for converter code that is all in one place.

Wednesday, December 31, 2014

Day 1 - 30 Day Challenge

Day 1: Learning AngularJS (vs Etoys)

So I have decided as I learn AngularJS to compare it to Etoys.  Admittedly not a fair comparison as both server different purposes, but hey its my learning journey and I will go where my strange mind and interests take me (I have found this path mostly useful and a lot of fun).

I am Shaping up with Angular.js from Code School.  I completed the first two levels.

So today I learned about:

  • Modules
  • Controllers
  • some directives
    • ng-repeat
    • ng-show
    • ng-hide
    • ng-src
  • Filters (uppercase, lowercase, currency, date, etc)
  • and some things about Bootstrap
The examples used in the course center around displaying a set of product data on the web.

I found myself thinking about how you do things in AngularJS vs how I would do it in Etoys.  Why you may ask would I want to compare two very different things?  Well while they are different at a very high level they are both tools for expressing ideas and both use MVC (Model View Controller).  Now when I say MVC I am not talking about the "modern" definition and use as found in various web frameworks such as AngularJS etc, but in the original definition from Trygve Reenskaug:
"The essential purpose of MVC is to bridge the gap between the human user's mental model and the digital model that exists in the computer." (see here)

Also I feel by trying to compare two very different approaches and trying to get to the "essense" of what they do and how they go about it I may actually gain some slightly deeper understanding.

I actually spent some time trying to build "directives" in Etoys and and while I created a "toUpperCase directive" and mapped a set of data (in a Holder) to a "Form",  it didn't feel right.  

I then recalled Dan Ingalls. The Live Web - Drag 'n Drop in the Cloud (video, JS CONF USA 2012) talk and thought that using connectors and converts would be a better approach. Basically I really like the idea of "connecting to a data source" then writing a converter to massage the data into a format that can be received by a visualization tool (table, list, graph, etc).

Cheers,
Stephen



Tuesday, December 30, 2014

The 30 Day Learning Challenge

Martha Graham
“I believe that we learn by practice. Whether it means to learn to dance by practicing dancing or to learn to live by practicing living, the principles are the same. In each, it is the performance of a dedicated precise set of acts, physical or intellectual, from which comes shape of achievement, a sense of one's being, a satisfaction of spirit. One becomes, in some area, an athlete of God. Practice means to perform, over and over again in the face of all obstacles, some act of vision, of faith, of desire. Practice is a means of inviting the perfection desired.”
― Martha Graham
Sadly I have not been able to spend much time writing code, which I really enjoy.  I am working with people who code, reading their code, specifying requirements and on rare occasions doing code walk throughs.  
So I have decided to take it upon myself to "practice" coding everyday for the next 30 days.  My initial thoughts were to practice coding in EtoysJS or  lively-web and perhaps I will get there at some point.  But the pressures of work push me towards AngularJS at the moment so I will start there. That said I also intend to use this not just to practice programming but to explore other topics of interest such as how to teach programming.

Johann Sebastian Bach
“What I have achieved by industry and practice, anyone else with tolerable natural gift and ability can also achieve.”
― Johann Sebastian Bach

Aristotle
“For the things we have to learn before we can do them, we learn by doing them.”
― Aristotle, The Nicomachean Ethics




Friday, August 15, 2014

Gigascale Engineering talk by Bruno Bowden

Bruno Bowden (engineer on Google Earth, Enterprise Gmail) gave a great talk on "Gigascale Engineering"

He shared a lot of wisdom, which as the old saying goes, came from a lot of experience, which came from a lot of mistakes (including almost bringing down Gmail, messing up Eric Schmidt's email and having Santa Claus nearly cause an international incident.)

To summarize his points:
  1. The best decision is "Not to build"
    Learn to fail fast, give up and quit
  2. Recycle
    re-use, don’t re-invent the wheel.  Benefit from someone else's headaches and hard work.  Use something that's been battle tested, and someone  else has already worked through the bugs
  3. "Above the fold"
    Example he used was how one change, moving the download button up in the page so for certain displays with low resolution the download button could be seen w/o scrolling, increased the number of downloads of Google Earth by 50-100 million.
    My interpretation was find what will have the biggest impact.  Not what you think is will be cool or  interesting.

Then their was a really interesting section of the talk on "Pushing the reliability/Innovation curve". He showed how simple curve where the more innovation, the less reliability.  The "pushing" involves ways in which you can decrease risk which still increasing innovation. 

Below are a couple of the ideas he shared:
  • He talked about the basics such as Code Reviews.
  • He also mentioned that while Google "doesn't do TDD" all code is "guilty until proven innocent".   He stressed they do unit testing etc, they just haven't don't but into the "though shall always write tests first" approach.  My thought is that people trump process and TDD may add most value when used with less "experienced" developers to help them stay out of trouble.  That said I do like TDD, but frankly don't always practice it.
  • He mentioned that the number one threat to Google software was Google engineers.  And how they set Rate limits (throttling) to keep people from bringing systems to their knees
  • Using an exponential backoff strategy on retries to limit potential damage.  This reminded me of retry schemes for collision detection on Ethernet.  
  • Having built in "Real Time Controls" designed into the system to help you deal with performance issues
  • Having a way to safely/canary in the coal mine test knew code
  • Using N+2 Rollbacks
  • The advantage of "Keeping it Simple" and how engineers seem to love to create complexity.  A charge I have been guilty of way too many times.
  • He used a quote from John Dean "Design for 10x" which I understood as design for a 10 fold growth.
  • The earlier you can compartmentalize things the better before it becomes a Monolith
  • How when you first startup up you want to push things out as fast as possible and iterate quickly so you can find out what works (and hopefully abandon quickly what doesn't).  But once you start to scale you need to shift to a regular release cycle and a more repeatable process
  • Using protocol buffers to help deal with multiple versions of the protocol as you upgrade on a large multi-server environment.
  • Importance of managing your managements expectations.  Yes change is risky and when we do this there will be some fires (of course you go through the risk/reward analysis to determine its worth the fires that will happen).
  • What to do when failure happens (really important and unfortunately I see too many cases where this isn't handled properly or if they do the Post Mortem, the actions are not followed up on):
    • Alert Early - ie: don't hide the problem or cover it up.  Let people know so you can start to deal with it and get some help.
    • Escalate Response - Get some help, don't try and solve it all yourself, especially if its a potential crisis in production.
    • Stabilize - revert if necessary, but stabilize the system
    • Perform a Post Mortem - Ask "How can we avoid this in the future",  usually there are multiple points of failure.
    • Where could we have done more "Defensive Engineering"
    • Reassess the risks/rewards of what you are doing.
In addition to the wise advise there was a great story about how Santa Tracker almost caused an international incident, by flying over Toronto, Ohio (well he said some Toronto in the US, so I assume Ohio) as opposed to that other one in Canada.  Fortunately the Canadian general was kept sufficiently distracted so that he didn't look at the Santa Tracker until Mr. Claus got back on course.

Here is his Ted Talk on Santa Tracker:

Cheers,
Stephen