Python Education Summit 2014 Call for Papers

February 15, 2014

Python Education Summit 2014 Call for Papers

Do you have a story to share on education and Python? We are actively looking for presenters for the Python Education Summit and have extended the submission deadline. Please submit a topic you would like to present on. Interested in seeing the topics others are proposing to speak on? Have a look and vote for your favorites – help us define this year’s agenda.

Need some ideas for topics you could present? Maybe one of these topics will inspire you to share your experiences:

  • The joy and pain of authoring a book on Python
  • Teaching Python on a shoestring budget
  • Gamifying how you teach Python to strengthen engagement and return on investment
  • Using the Raspberry Pi to teach Python
  • Tips for developing your Python-based curriculum
  • How to choose what to teach
  • Educating children to program in Python
  • Educating seniors to program in Python
  • Helping a student transition from Learning Py to Py Employment
  • How to make money teaching Python
  • Developing a community program teaching Python
  • Train the Trainer: teaching volunteers to teach Python
  • Exploring the resources available to instructors
  • Choosing the right teaching resources
  • Taking a student to the next level – guiding ‘self study’

If you are interested in presenting, please submit your ideas for topics/presentations that you would like to present. We will gather feedback on the submissions to assist us in building the agenda. All submissions must be in by February 25th and decisions on speakers/presenters will be made and speakers will be notified by February 28th, 2014.

NOTE: All speakers will be offered early bird pricing for attendance at PyCon.


Quick Python Book is Manning’s Deal of the Day April 12

April 11, 2013

The Quick Python Book is Manning’s Deal of the Day April 12!

That’s right, starting at midnight EDT, April 12, my book, The Quick Python Book, 2nd ed will be Manning’s Deal of the Day. What does that mean? It means that if you click on the link at the right and buy the book or ebook using the code dotd0412au, it will be half price. This deal will only last for a day or two, but it’s a good chance to pick it up a really good price! 

And the author will thank you! :)


Another Quick Python Deal

January 19, 2013

Just a quick note that the Quick Python Book, 2nd edition will be Manning Publications deal of the day Saturday, May 18. 

Here’s the official scoop:

Deal of the Day : Half off my book The Quick Python Book, Second Edition. Use code dotd0518au at http://www.manning.com/ceder/.

Also on the same code is Hello! Python (http://www.manning.com/briggs/) and Extending jQuery (http://www.manning.com/wood/)

And for anyone in Europe and the Americas, you should know that the deals usually run until past the end of day everywhere in the world. So if you don’t get it done on Saturday, the code might still work on Sunday morning. Just sayin’…


Number 2 for 2012

December 31, 2012

I’ve already put this on the social networks, but I can’t resist noting that The Quick Python Book, 2nd ed, AKA my book, was the second best selling book for Manning Publications in 2012. And I can’t even complain about missing number one, since that slot was claimed by Warren and Carter Sande’s excellent Hello World! Computer Programming for Kids and Other Beginners, another Python book! Python in the top two spots! 

As I’ve mentioned elsewhere, if you use the link at the right you can pick up either title for 50% off before the end of 2012 by using the code bestof2012

As for me, I’m just blown away that QPB2e did so well.

Happy new year to all in the Python community and thank you!


A few changes

October 26, 2012

This is a completely non-Python related post, but it probably makes sense to post this here, just for the casual observer. There have been some changes in my personal life that may make things confusing for some. I’ve been pretty public about this on my social media accounts, but quite a few people haven’t heard for various reasons, so here is the news.

 
The short version is that I’m transgender and I’ve legally (and emotionally, professionally, etc) transitioned to being female. So the Naomi you see now is (in some ways at least) the same as the Vern that used to post here.

 
That is all. :)


Turtlelab – A Simple Environment for Teaching Python

June 17, 2012

I started teaching Python to 8th graders years ago. We were already teaching it to all of our 9th graders, so I talked the 8th grade computer teacher into it (pretty easy since a) she was as very smart woman, and b) I was sort of her boss ;) ) so that we could build a little buzz for programming before kids made it to high school. I started them just with IDLE and some text based programs, followed by some stuff from the LiveWires lessons and it was a modest success.

However… I felt I was spending too much time on the mechanics of using the environment and not enough on the actual prorgramming. This mattered since we could only carve two weeks out of the existing curriculum for the programming unit. I’d also switched to a curriculum completely based on using Python’s built-in turlte module, which became much easier when some us added several tweaks to the library for the 2.5 release, and even easier when Gregor Lingl’s brilliant x-turtle was adopted as the replacement for the turtle library in Python 2.6.

Still, I wanted an even more supportive environment than IDLE. I wanted something that would take care of saving – kids forgetting to save was pain in the rear, and a good way to kill their enthusiasm. I also wanted something that would offer help on the commands as they were starting out. Not code completion, exactly – for novices that can more confusing, but something that would enable them to find the command they wanted easily without leaving the enviroment.

So… I created my own. I used it and thought it worked pretty well, but never really got around to promoting it. Then Simón Ruiz started using it to teach our 9th grade class. Simón polished and refined the interface based on his experience and testing, and the result, if I do say so, is worth a look if you want to teach Python to kids using the turtle. It has the great advantage of being a single file, so installation is easy, and its only dependency is that it requires Tkinter and IDLE.

At the moment Turtlelab isn’t really under active development – I’ve since left teaching and Simón has other assignments, but I believe he’s considering a blog post or two in the near future focussing on it. 

Rather than explain it in great detail, I’m sharing the link to the BitBucket repository and you can go play with it yourself. And if you really like it and want to use it, please do. If you like it even more and want to take it over, please let us know – we love to have it in use and under development.

Get Turltelab here.


How Not to Get a (Python) Job – a rant

May 27, 2012

How Not to Get a (Python) Job – a rant

At PyCon 2011, Brian Moloney (of Imaginary Landscape here in Chicago) gave a talk titled How to Get A Python Job”. It wasn’t really so much about getting specifically a Python job as about how to land any job. It was the same sort of advice you can find in a lot places – hints on how (not) to apply, how (not) to present yourself, how (not) to interview, how (not) to impress interviewers, and so on. If you’re looking for a job, go watch it and take his advice very seriously.

I went to Brian’s talk because I had just found my own Python job and I was curious about his perspective. I had started my own job search with my fair share of negatives – the economy was in the toilet, I was over 50, I didn’t have much formal training, my experience (in private education) wasn’t exactly mainstream, etc. And yet within 3 months of sending out my first resumé I had a job, and even had to turn down other offers. Even as I settled into my new job, I was frequently contacted by recruiters looking for Python programming help. And yet, I’ve heard many people complaining quite vocally about how difficult it was (and is) to find programming jobs in general and Python jobs in particular.

As the IT director and lead developer at a startup trying to grow its tech staff, I’ve been heavily involved in searching for and interviewing developers. In that process I’ve seen people of all ages and backgrounds painfully ignore the basics of getting a job. So the idea behind this post is to put one more voice out there, sharing some of the things that make me not want to hire an applicant.

Here are the things that make crazy. Take from them what you will.

Not knowing the market. Several candidates have said, “it seems like no one is looking for Python people.” Say what? I get called regularly by recruiters looking for Python developers. We’ve been searching for a Python dev for months. Admittedly, the market is better for more experienced people and you might need to relocate, but even junior Python dev positions are going begging. Ask any recruiter, we’re a hot commodity. When someone tells me that no one is hiring for Python, that tells me one of two things… either that person doesn’t know the job market (at least around here), or they aren’t really a Python developer. In the first case, I’m a pretty firm believer that the responsibility for finding jobs lies with the job seeker and not having done research on the market it a bad sign. If you don’t care enough to do research to find your own career, why should I expect that you’ll have the initiative to solve problems and help our team move forward? And the alternative is worse – in a market where knowing how to spell the word “Python” (at least on a resumé) should get you at least a few calls, not getting any traction is a red flag.

Not knowing the craft. This is so obvious that it shouldn’t need saying… except for the fact that it needs saying. “If you’re applying for a Python programming job, you should know as much as you can about Python and programming.” That means a basic understanding of the language, some basic knowledge of programming, some familiarity with the common or hot tools and technologies, etc. Obviously the depth of that understanding will vary depending on your experience, and for junior positions, particularly, you’re not expected to know everything, but you still should have some idea of the field.

I’ve interviewed candidates who couldn’t tell me how they would approach a problem, or what libraries they would use (or even have used), who’ve never even heard of Django, and so on. I’m no fan of springing little programming puzzles on candidates, since to my mind that mostly tests the ability to solve little puzzles, and I don’t expect lengthy dissertations on advanced programming topics, but I do expect you to be able to know the basics of coding and Python syntax, to have at least a nodding familiarity with current technologies, and to be able to discuss the approaches, tools and pitfalls involved in some of the coding you’ve done.

And speaking of the coding you’ve done, particularly for junior developers, you may not have done that much professionally. However, if you haven’t done anything outside of classwork, I’m going to be pretty skeptical. There are tons of opportunities to get involved in open source projects, to create your own web site, to help with something for a business, a club, or even just scratch your own personal software “itch.” It doesn’t matter how big or how successful your projects were, what matters to me is that you’re interested enough to be in the game on your own time.

Not knowing us (and the job). It’s been said before, but if you don’t care enough to do some research and thinking about us and the position before you come in for an interview, why should we think you’ll care once you’re hired? You’ve got the job description, probably some names of people at the company, and the entire Internet as resources. Even if you don’t have absolutely all the information, you should be able to find out enough to ask questions and maybe even float trial solutions. Why do you do x? How do you deal with issue y? Have you ever thought of trying z to solve this problem? Even if you’re completely wrong about your assumptions, the very fact that you’re thinking about our business is very compelling. If you want to be really sneaky talk about how “we” might solve some of those problems together.

And speaking of sneaky (not really, since it’s clear if you’ve done it or not), if you know who you’ll be interviewing with, look the people up online. Google and LinkedIn are your friends here. At worst you’ll have a feeling of control during the interview and at best you can work in a comment or question relevant to the interviewer’s background, which is almost always good. I’m not going to support hiring you just because you looked at my LinkedIN profile, but it does tell me you cared enough to do some research, and that’s a good thing.

Not selling yourself. Don’t go into your shell – there is a job open and somehow you’ve gotten an interview. So take advantage of it! You may be an introvert, it may be hard to talk about yourself, or maybe you just don’t think you should have to “market” yourself. Whatever… but in this situation you’ve really got to go for it. Show us how interesting you are, how much you care about the work, how cool you think the job is, how much you would bring to the team. If we hire you, we’ll have to work with you every day, so why should we look forward to that? (In a business sense, of course – promising to keep everyone loose with dirty jokes is probably not be the way to go here.)

We can only hire a few people and we need to get a lot of stuff done. We have lots of problems crying out for solutions so we want someone who is eager to tackle those problems and has some chance of succeeding. As Joel Spolsky succently put it, “smart and gets things done.” You may not have the exact sklls to fix every problem at this moment, but that’s not the entire point – as a startup none of us had the exact skillset for this business when we started. But all of us were ready to dig in, we figured it out fast, and we got the job done. And that’s the sort of person we need.

Note: this is not the same as emphasizing how good this job would be for you. I understand that you want to move from that old job to a new, more interesting area. I applaud the fact that you just love to learn new things. I’m totally on board with how wonderful this opportunity would be for you… but we need to move and scrub a ton of data, polish the UI, analyze customer behavior, and keep thinking of new ways to stay ahead of the game. How are you going to help us do that?

Please feel free to ping me with comments or questions: comments are not automatically published, so if you have a question or comment, please feel free to leave a comment and indicate if you want it to remain private.

Edit: If you’re looking for Python jobs you might try the Python Job Board, which as it happens is where I found my current position, or the PyCoder’s Jobs site (I have no direct experience with this one, this is not meant to be an endorsement), which is dedicated to Python jobs and run by the same people who do the Python Weekly newsletter (which I do find very useful, actually.)

[edited to add company name and contact info]


ISTE, Python and Robots

June 28, 2011

Monday I was at the ISTE (International Society for Technology in Education) conference in Philadelphia to give a version of the same talk I gave at PyCon in March, talking about my experiences teaching Python using the combination of Scribbler robot and Fluke bluetooth board developed by Georgia Tech and Bryn Mawr. I think the talk went reasonably well – 50 or so attended, and they laughed in the right places, which is my main criterion for success. I also got to say hi to a few old acquaintances and even meet a couple of new faces with Python edu-sig connections.

Although I was talking about a class I’d taught, and combining robots with Python, the other point that I hope the audience also got was the need to make programming classes relevant, real, interesting, and above all, darned cool. As anyone who’s heard me talk about it knows, I’m happiest teaching project based courses where we’re free to pursue interesting topics as they come up. Writing a chat bot in Python, plotting the Mandelbrot set in Java, or trying to crack passwords in C, it’s the joy of tackling a hard problem and doing something really exciting that has driven all of my best classes.

It doesn’t have to be robots, or necessarily Python, but if kids don’t leave a programming class feeling they’ve truly done something pretty amazing, I think we’ve missed the boat. That feeling I think is key to getting a more diverse group of kids into the field (yes, I mean girls, but others as well) and it should be within reach – there’s so much amazing stuff they can do.

I’m not alone in this thinking, of course. Many of the edu-sig gang have done great work in this regard, including Jeff Elkner, Kirby Urner and Brian Brumley, and many others. But we’re too few, and too spread out. In general, the state of secondary and middle school programming instruction in this country reminds me of the old Woody Allen joke about the Jewish ladies at the resort, “The food is so awful here…”  “Yes! And such small portions!” We have to keep working on that from all sides.

I was also surprised to find that I was the only Python related talk at all of ISTE. I’m afraid the joke is right – if it doesn’t cost money, it gets no traction at ISTE. Similarly, there were only a few other open source related talks, a sad decline from my first couple of years at ISTE (then NECC) as the Python presenter at the start of the Open Source Pavilion. Then it looked like open source software might make a real dent in one of the most commercialized conferences I’ve ever attended. I could seriously say that I went to preach Python and open source at NECC because that’s where the unconverted were. Well, the unconverted are still there, and more numerous than ever, I’m afraid.

Still, there were some encouraging notes. Out of the 50 or so who attended my talk there was one gentleman who was trying to get programming classes offered by his school, and who thought that Python and robots might actually be the way to persuade his administration to try it. Another was reworking an established program to include more Python as the capstone language, because, as he put it, “all the colleges are switching to it”. I truly hope he’s right on that one.

Finally, thanks to my employer Zoro Tools (http://www.zorotools.com) for giving me the time to go make the presentation – go buy something
from us – we sell nearly everything. ;)

And even greater thanks go to the Python Software Foundation Board for supporting my trip. My rather quick departure from Canterbury for Zorotools.com had left my travel to ISTE unfunded, and the PSF stepped in to help me for the second time. That’s probably something that the PSF should brag about somewhere – what other open source programming language’s foundation has cared enough about education to send someone to speak at big conferences like ISTE? If others have, good for them, but I’m thinking it’s pretty rare.


PyCon Poster Session will be Amazing

January 23, 2011

As the poster session chair, I’ve been watching poster proposals come in for PyCon over the past several weeks. I was very happy with the posters last year, but this year we have a truly amazing collection. Since the submission deadline has been extended until Tuesday, January 25, (which is also the Early Bird registration deadline) I won’t name specific posters yet, but the submissions cover the spectrum.

There are posters on Python in the sciences and bio-informatics, on Python for education and citizenship, on new packages and uses of Python, and even a couple of posters that showcase Python as a tool for hardware hacking “makers”.  And every single one of them looks great. Every. Single. One.

As I recall the excitement in the room last year for the first PyCon poster session ever, I can only smile as I think of what the reaction will be to this collection. I promise you, people will be wishing that the poster session could last all day to give them enough time to inspect each poster and chat with every presenter.

Better yet, you still have a chance to join this impressive company. If you want to submit a poster, just swing by the poster session CFP on the PyCon site by Tuesday to submit a poster proposal.

See you at PyCon!


Not Python – AppInventor doesn’t quite do Life

January 10, 2011

AppInventor Test Drive

I’ve always been sort of fascinated by drag and drop programming schemes – the sort of thing where you use little graphical blocks to represent code structures. The simplicity of it appeals to me as a teacher of programming for one thing. And I’m not alone – this idea is used in languages/environments like Scratch, which is gaining popularity in the school world right now.  The problem with languages like those is that they always seem to be limited – they’re too cumbersome to write much of a program. And for teaching languages, sometimes that’s OK.

Recently, I decided to try a drag and drop language with at least somewhat higher expectations – Google AppInventor. I’d written a few little test apps using AppInventor – a clock, some tests of location, buttons and colors, and one where I could “roll” a ball around the screen by tilting the phone, and it looked like it had some real potential.

A Real Test – Life

That led me to try writing Conway’s Life. I like Life because it’s fairly easy to write (I make my AP Comp Sci students write it every year), it’s fun to look at, and yet it asks a certain amount from a language – 2 dimension arrays, a fair amount of processing, some screen redrawing, etc.  I know that following a discussion of Alice, our tech support specialist, Simón, wrote a version of Life in Alice, which was painful – it required huge contortions to create a 2 dimension array of cells, and was painfully slow with even a 10 by 10 world.

So New Year’s day (yeah, I don’t really follow bowl games ;) ) I started on it and made a fair amount of progress. Some things were actually easier than I expected. Creating a 2 dimension array as a list of lists was obvious for a Pythonista like me, and drawing the cells on the canvas was also dead easy.

Other things were not quite so straightforward, but still no real problem. For example, AppInventor doesn’t have a “counting” for loop, but only a “for each item in a list” loop. That meant to get the indexes I needed to check surrounding cells I had to use while loops and manual increment counters, but that was no big deal.

So after an evening of messing with it and looking at the documentation, I was in pretty good shape – I had a 20 by 20 “world” or cells which I could randomly set as alive or dead and I could iterate through that world and draw dots on the screen for the live cells.

Frustrations

At that point frustrations started to set in. The first frustration wasn’t really AppInventor’s fault entirely, but rather just the nature of the coding by blocks interface. I soon found the process of coding by blocks very irritating. Switch to the right block pallet, drag out the block you want, set initial values, then drag into place, rinse and repeat. It doesn’t seem so bad when you first start out, but keep in mind that everything is a block. For an if statement comparing two items, you need four blocks – the if, the comparison, and each item. When you know what you want to do, repeating that process gets very tedious very fast. In fact, I started wishing I could just open a window and type in the code. Of course, a little tedium never stopped me, so I pushed forward.

The second frustration ended up being a bit more of dealbreaker. In its current incarnation, AppInventor allots a fixed size panel for assembling blocks. As my logic got more complex, my stacks of blocks grew until they spilled off of the panel. That could have been survivable, but then I found I couldn’t edit the parts off the panel, and I couldn’t move the stack so that the bottom end would stay on the panel. You can zoom in and out, but that doesn’t change the relative size of the blocks compared to the panel.

At that point, just short of getting the rule processing finished, I gave up. I suppose I could have gone back and tried to break things down into smaller functions or pulled my stacks apart for editing and the stuck them back together, but I had simply had enough. And I had already broken things down so that the functions would have been under 30 lines of Java or so. It’s not an intrinsic limitation, of course, but for the moment it does limit the code you can write. That was the issue that made me give up, although I might have struggled on a bit if there hadn’t been one other issue.

And speed…

I also ran into a issue with processing speed. There isn’t any. Running on a Droid Incredible, it took 2-4 seconds to process and draw a 20 by 20 world. That’s pretty shocking. After I gave up on the AppInventor, I wrote a similar implementation of Life in Java and doing the same processing and drawing seemed to be nearly instantaneous, to the point that I needed a 200 ms. delay in the processing loop. (For the record, I never got to the point where the AppInventor version was looping to update, instead I was starting each generation with a button press.)

Conclusions

In spite of the fact that it failed my Life test, I find AppInventor an interesting tool. As a teacher, I can see it being useful for introducing programming to non-programmers. The blocks should make things easier to manage and understand, and the coolness factor of writing an app for your phone would boost motivation. It also is good as GUI-based “glue” for the OS, which I’m sure was one its primary purposes – you can tie several different bits of the phone’s functionality together pretty quickly. Building on this I can see a use as almost as an interface generator – whipping up a quick UI that then calls other code (maybe written in Python for the ASE?) and grabs the results. As I get time, I’m going to experiment with this.


Follow

Get every new post delivered to your Inbox.

Join 128 other followers