Friday, January 22, 2016

Artificial Intelligence Simplified: Understanding Basic Concepts

I am officially a published author!

I co-authored a book called Artificial Intelligence Simplified: Understanding Basic Concepts.  My expertise is not in AI, but I am skilled at bringing technical content to more general audiences.  So my co-author Binto George wrote the text, and I helped transform it into an informal, tutorial-style overview of the basics.

The book grew from what was originally going to be a chapter in a larger volume that touches on many different areas of computer science.  Our philosophy was that learning in context was more effective, so each chapter was going to have its own motivating question.  For example, in my first chapter on data representation (which will likely make it into a book of its own), my question was "How did photography go digital?"  The AI chapter's context was healthcare, which we decided to stick with in the expanded stand-alone book version.  The result is an introductory book that discusses the main ideas of the field in the context of a few problems found in healthcare, such as scheduling surgeries for an operating room.

Here's some info from the back cover of the book.  Go check it out on Amazon (Canada, US).  There's a cheaper student version floating around as well.
Artificial Intelligence concepts explained using real-life examples. No complicated math or jargon.  
Have you ever wondered what Artificial Intelligence, or AI, is all about? Let us guide you through the key concepts of AI with our friendly, tutorial-style explanations. We use everyday language and concrete examples in the context of healthcare to ensure things don’t get too abstract. Whether you’re a complete beginner who’s curious about AI, a student who’s intimidated by the technical nature of traditional textbooks, or even a robotics enthusiast who just wants to get started with AI, this book is for you.

Monday, January 11, 2016

PhD: On Hold

I've sent in the forms.  I've updated my committee.  The deed is done.

My PhD is on hold.

Pause / Rafa Puerta

More officially, I am deregistering from the program in good standing.  I am giving myself max one year to reevaluate, but my intention is to eventually reapply and finish my thesis.  I don't need the degree right now, which is why I feel ok putting it on hold, but I do want it in hand eventually to open some doors in the future.

I have been on leave from the program since September 2015.  It seems that I could get another semester of leave, but I don't think it will be enough.  There's an exciting new education project at work.  I unsurprisingly found my way to it, and even have the opportunity to lead it.  It's on the ambitious side, so I want to make sure I can focus all my attention on its success.  Worrying about my thesis seems like a distraction for now.

All I need to do is finish my project and write my thesis.  ("All.")  I've completed coursework, comprehensive exams, and even the thesis proposal.  I do have a lot of development and experimentation work to do, but once that's done, I shouldn't have that tough of a time writing the dissertation.  I like my project and want to see it through.  It just doesn't have to be right now.

Wednesday, November 25, 2015

Review / Ruby on Rails Tutorial: Learn Web Development with Rails by Michael Hartl

When I started at Shopify in the summer, the only Ruby I knew was from reviewing a children's book, and I didn't know any Rails at all. So I needed to get up to speed, and fast. Michael Hartl's Ruby on Rails Tutorial was my first, and still my favourite, go-to resource.

You can buy a copy of Hartl's tutorial, or read it for free online. If you buy it, you can also get supplementary learning material like solution manuals and screencasts. So far, I've just been working through the online version and skipping the exercises found at the end of each chapter (though I think the exercises are worthwhile, especially if you are not using Rails at work in parallel to learning it).

The coolest thing about this tutorial is the partnership that Hartl set up with Cloud9, a cloud-based development environment. When you're just getting started with something new, it is very helpful to avoid the headaches that inevitably come with setting up your own machine for development. Instead, you can use the tutorial-specific, preconfigured workspace on Cloud9 that leaves out only exactly what Hartl wants to walk you through. It's also really easy to deploy to Heroku from Cloud9, allowing you to easily test your website in production.

The structure of the book is well thought out. You get to make a fully functioning, if simplistic, web app in the first chapter using the automation tools available in Rails.  In the next couple of chapters, some of the key concepts of Rails are introduced and you learn to create static pages.  Chapter 4 delves into some Ruby-specific programming concepts. I'm not sure how well a beginner would be able to program after reading a single chapter, but then again, I'm not sure how good at programming you even have to be to write a small, straightforward Rails app anyway.

After the introductory chapters, the rest of the book is devoted to creating a Twitter-like micro-post website. A lot of the initial focus is on users, which makes sense pedagogically: it allows the learner to focus on the key concepts surrounding information stored in a database with a single model, which makes it a lot less confusing. The downside is that you don't get to the actual micro-posts, the meat of this particular application, until chapter 11. I found myself losing interest by then.

Overall, though, this is a great way to learn Rails, especially if you have some programming background, and probably even without any. The language is clear, direct, simple, and friendly. The examples are carefully designed to introduce as few concepts at a time as possible. Highly recommended.

Thursday, October 29, 2015

Connections: Learning Science, Games, and Apprenticeships

I'm working on an education project that isn't ready to announce yet. In so doing, I've been taking another look at learning theory, game-like learning, and apprenticeships. Unsurprisingly, there are many connected ideas.

Close connection - Verbundenheit
Close connection / Daniela Hartmann

There's a great book called How People Learn: Brain, Mind, Experience, and School that you can read for free online. The introductory chapter aims to separate speculation from science, summarizing some of the key concepts and practices covered in the rest of the book. Part of this is a research-based list of attributes that good learning environments ought to have:

  1. "Schools and classrooms must be learner centered." Consider cultural differences between students, and foster a growth mindset over a fixed mindset.
  2. "To provide a knowledge-centered classroom environment, attention must be given to what is taught (information, subject matter), why it is taught (understanding), and what competence or mastery looks like." Avoid presenting a large number of disconnected facts, and don't design tests that favour memorization instead of understanding. Doing with understanding is more important than just hands-on doing.
  3. "Formative assessments—ongoing assessments designed to make students’ thinking visible to both teachers and students—are essential." Use formative assessments to allow students to experiment with and revise their understanding and track their progress.
  4. "Learning is influenced in fundamental ways by the context in which it takes place." Make the norm of your learning environment one that encourages risk-taking, mistakes, feedback, and revision.
Meanwhile, one of my favourite examples of game-like learning (that is, applying what we know about learning in good games to more traditional forms of education) is NYC public school (grades 6-12) Quest to Learn. Seven principles of learning are outlined in the Q School Design Pack, directly quoted below:
    1. It kind of feels like play: Learning experiences are engaging, learner-centered, and organized to support inquiry and creativity.
    2. Everyone is a participant: A shared culture and practice exists where everyone contributes, which may mean that different students contribute different types of expertise.
    3. Failure is reframed as iteration: Opportunities exist for students and teachers to learn through failure. All learning experiences should embrace a process of testing and iteration.
    4. Everything is interconnected: Students can share their work, skill, and knowledge with others across networks, groups, and communities.
    5. Feedback is immediate and ongoing: Students receive ongoing feedback on their progress against learning and assessment goals.
    6. Challenge is constant: A “need to know” challenges students to solve a problem whose resources have been placed just out of reach.
    7. Learning happens by doing: Learning is active and experiential. Students learn by proposing, testing, playing with, and validating theories about the world.
    I'm sure you are already seeing the connections. For example, the learner-centred theme appears in both lists, formative assessments to revise thinking is similar to failure reframed as iteration, and context and practical experience are important throughout. Of course, this is no accident: The Institute of Play, the organization behind Quest to Learn and similar schools, have done a lot of careful research into both learning and games. Even without the more obvious game-based approach of Quest to Learn, game-like learning principles are useful to apply to any educational initiative.

    Finally, I have also been learning more about apprenticeships, particularly for software developers.  In the introduction of another freely available book, Apprenticeship Patterns, software craftsmanship is defined as a community of practice with a common set of underlying values. Many of the values listed tie again to the ideas described above. For example:
    • An attachment to Carol Dweck’s research, which calls for a ‘growth mindset.’” How People Learn calls for a community in which the growth mindset is the norm.  Failure as iteration shows students that they don't need to 'get it' the first time, but instead work toward mastery.
    • "A need to always be adapting and changing based on the feedback you get from the world around you." Formative assessment provides opportunity to react to feedback, and in game-like settings feedback is always coming your way.
    • "A belief that it is better to share what we know than to create scarcity by hoarding it." Game-like learning encourages sharing knowledge broadly.
    • "A willingness to experiment and be proven wrong." Again related to failure as iteration.
    • "A strong preference for what Etienne Wenger calls ‘situated learning.’" Communities of practice are one part of Wenger's situated learning theory, which relates to the idea of learning in context and learning by doing.
    I'll be delving deeper into a lot of these ideas and seeing how they will apply to the project I'm working on. Perhaps the perspective from the three different angles presented above will help you in your own projects, as well.

    Monday, October 19, 2015

    Transitioning From Academia to Industry

    It seems that 2015 has been a year of change for our family.  My husband got a new job in February, we somewhat suddenly decided to buy a new house down the road over the summer, and I was unsuccessful at getting a permanent teaching position at Carleton.  Rather than becoming a full time student to wrap up my PhD, however, I decided to jump ship to industry.  And so I am currently a developer at Shopify here in Ottawa.

    change / Andrea NIgels

    When I decided to go to industry, I had my sights on Shopify and only Shopify.  Many of my friends worked there, and I felt like it was the kind of place I could make an impact.  But I was really nervous about interviewing – would they want someone who had been locked away in the ivory tower since her co-op days in undergrad?

    Mind you, I have always tried hard to remain 'useful' in the industry sense.  I figured it would keep my teaching relevant if I got the permanent position, and it would help me break back into industry if not.  While I didn't work on any large-scale team projects during my grad school years, I did choose an application-heavy research area and was mindful to maintain good development practices where I could.

    Clearly, it worked.  I had interesting projects to talk about during my interviews, code to show on my GitHub, and despite my nerves, I did just fine for the pair programming part.  I showed I had a strong technical base and a boatload of passion.

    Once I managed to get hired, I wasn't so nervous about actually starting a few months later.  Which is interesting, since I didn't really know Ruby or Rails, the language and framework I'd be working in.  I suppose I felt confident in my ability to learn new things quickly, and I can't say I was wrong.  I still don't know Rails deeply, but I have been able to learn what I need as I go.  My aforementioned conceptual base along with my enjoyment of the design aspect of programming have made it easier.

    And so my transition from academia into industry has been a good one.  It's been nice to keep more regular working hours, and it's been fun learning new technologies.  If I hadn't had 20 months of co-op experience in undergrad, or continued to practice throughout grad school, the switch would have been a lot rougher.  If you're a grad student, strongly consider industry-based internships and make sure to learn the tools of the trade (starting with version control!).  With a strong base and a little confidence, you can make the switch, too!

    And as for my PhD, worry not: I am on leave this semester, but I do hope to (slowly) get through it eventually.  You'll have to wait for the "how to work full time while working on your PhD part time" posts a while longer. ;)