We use basic building blocks, like musicians do, in order to build programs. These building blocks are called "design patterns". Just like music, we know that programs can be built without using design patterns, but they are generally more pleasing to read and understand if we do use them. These patterns are recognisable to other programmers with the same training and understanding.Read More…
If you end up working as a developer, for any sort of large corporation, it is practically inevitable that you will be pressured to go into management. This is doubly true for women. What? you say... Yup, there is just as serious a gender gap in upper management, to go along with the gender gap in developer roles. The powers that be want to get as big a pool of middle managers as possible to choose from, so they can start filling that gap.
Don't do it. Really, if you like to code, you will probably hate management.Read More…
What is National Girls Learning Code Day all about?
It's about discovering a passion for learning about technology.
It's about experiencing the satisfaction that comes from being a builder/maker of the web and technology.
It's about building a simple one page website from scratch to share with friends and family.
And becoming more confident and self-assured and developing a willingness to try new things.
This is a beginner level workshop for girls 8-13 years old and their parent/guardian/aunt/older sibling.Read More…
That's right, we now have an official Lethbridge Chapter of the Ladies Learning Code, with an email, and everything.
To launch this chapter with a BANG, we are holding our first workshop in conjunction with the 3rd Annual National Learn To Code Day on September 26, 2015. With the help of Facebook, Telus, and the Government of Canada we'll be teaching Python to absolute beginners!Read More…
Let's get this one question out of the way, right off the bat. Why RSpec? or more specifically - why RSpec instead of MiniTest?
For me, the answer was provided with a simple empirical test. One of my junior developers desperately wanted us to use RSpec on our project instead of Test::Unit (precursor of MiniTest). We decided it to give it a trial. I don't think we wrote tests faster. Or that the specs ran faster. But... my fellow developers on this project wrote better tests by far than they had been writing using Test::Unit.
Better tests in this case mean... more finely grained, better focused. Where before we wrote a single test with 15 or more asserts, now we wrote 8 or 10 specs, most with single expectations.
While I am certain that it was possible for these developers to write better, more finely grained tests using Test::Unit and a little discipline, I am also convinced that we wrote better tests by default in RSpec, because of the way in which the specs are structured, and described.
So ever since, I have advocated for RSpec on every project I work on.
Now, it does take a little longer to get up to speed using RSpec, but once you have the basics down, the rich environment of the RSpec core, combined with separate libraries for expectations & mocking provide both power and flexibility. If you don't like rspec-mock, you can go ahead and substitute the mocking/stubbing framework of your choice. And rspec-rails provides a drop-in replacement for the default Rails testing framework.
The RoR4Real Advanced Topics workshop - Better Testing with RSpec - will help you over that speed-bump of getting started using RSpec, and introduce you to the full power of the RSpec environment covering:
- RSpec basics
- Setting up your project with RSpec
- describe & context blocks
- expectations in detail
- using test doubles
- rspec-rails intro
- More advanced concepts
- writing your own matchers
- the power of factories
- integration testing with Capybara
So, to get back to the original question, "Why RSpec", let's see what one of the authors of The RSpec Book had to say:
RSpec is not just about RSpec. It's about BDD. It's about encouraging conversation about testing and looking at it in different ways. It's about illuminating the design, specification, collaboration and documentation aspects of tests, and thinking of them as executable examples of behaviour. -- David Chelimsky
And that's why I use RSpec. If you'd like to write better tests in RSpec like a pro, you should sign up (and get 50% off!!) for one of my Advanced Rails Workshops now:
I had the opportunity last week to teach one of the Calgary based Girls Learning Code workshops for the first time. It was quite a learning experience, for everyone, so I thought I'd write up some of the fun things we learned.
I was asked if I'd be interested in teaching this workshop back in December, and I immediately said yes. Having already taught and mentored for the Ladies Learning Code workshops, I thought teaching kids would be fun. Like the LLC workshop, I knew that this workshop had already been given in Toronto, and that the materials from that would be available.
Ksenia asked me to review the materials, so I did. It looked like a "dumbed down", shorter version of the adult workshop. In a fit of laziness, I just said it would be fine. However, when Ksenia followed up with me, and mentioned that the material was a little ... dry, and lacking in "fun factor", I had to confess to having similar thoughts. So, I started investigating ways of making the workshop "more fun".
The first thing that sprung to mind was KidsRuby.com. After a quick review of the website, and some of the training materials, I was sold, especially since KidsRuby has embedded Artoo.io, and you can program ROBOTS with it. I have a 13 year old nephew, and he absolutely loves the Sphero I got him as a Christmas present, after seeing the Artoo.io intro at RubyConf 2013.
Unfortunately, it seems that KidsRuby is in a bit of flux at the moment. The installers don't work on the most recent releases of OSes. It seemed to me that if we couldn't guarantee it would run for all the students in the class, we really couldn't use it. I did download the source materials for the installer and attempt to get the installer building/working so that I could fix it up, but I had problems with it, and no one was able to respond to my problem reports over the period of a couple of weeks), so I had to give it up. (Not throwing blame around here. Open source can be a labour of love, but sometimes real life gets in the way. I was on a schedule, however...)
So, we defaulted back to the basic RubyInstaller, the command-line, and editing files with Sublime Text. Not ideal for kids, and certainly more work for the mentors, but it was good enough.
Now, about those course materials...
I reviewed some of it, in an overview fashion, with my nephew. He agreed with my first impression that the Twitter example wouldn't be that interesting to kids. In his words... "Everyone HAS a Twitter account, but no one actually USES it." So, the Twitter example had to go.
A second issue arose from that review. The Madlibs examples are cool and a lot of fun. But the original class was presented to 13 year olds, who could all be expected to understand the parts of speech (nouns, verbs, adjectives, adverbs). In our class, we had 8-13 year olds (actually, we also had a couple 6 year olds o_O). At least some of those would need help with the parts of speech, so we added a quick little grammar review, and wrote some examples on the white boards during the workshop, so that the kids had help with their Madlib exercise. Lots of giggling involved, so I think they enjoyed it.
One thing did stick from KidsRuby - Robots. Because robots are cool. I bargained with my nephew, and he agreed to let me "borrow" his Sphero for the workshop, if he was allowed to come along. Seemed fair to me. He & I spent a fun afternoon getting everything set up to have a Robots! demo at the end of the workshop with his Sphero.
Cribbing heavily from the KidsRuby class notes, we replaced the Twitter stuff with some new basic logic material, and I introduced some basics on looping. The final version of the class material used is in this Github branch here. Once we covered all that, I was pretty sure that the students would be able to grasp the Artoo.io Sphero demo code without too much trouble.
I sent all that to Ksenia. She also suggested an "icebreaker" exercise at the beginning of the class, which was an excellent idea, and got the girls very engaged.
All in all, I was happy that we prepared so well. The workshop was well attended (most popular one so far!) with 22 students and 7 (or 8 or 9?) mentors, and went fairly smoothly. Had one hiccup, when the USB sticks I had prepared (with backup downloads and course materials) ended up formatted only for Mac #facepalm, but one of our fabulous mentors, Tim, was able to quickly re-format enough copies for all the Windows-based students to use. We did run out of time at the end, leaving the final exercise as "homework", but got our Sphero demo to run, just about the time that all the parents showed up to take the kids home.
I have to close by thanking the amazing Girls Learning Code team at @ChicGeekYYC. Ksenia, Darcie, and Jocelyn put in an amazing amount of effort to run these workshops, and to make certain that they are free. And to thank all the mentors who helped make my job as instructor pretty easy. I'm not certain if all the attendees and parents realize, but these Girls Learning Code workshops are free because of the efforts of the @ChicGeekYYC team, the instructors, and the mentors, all volunteering their time to teach coding skills to young girls. And, of course, the sponsors like @AssemblyCS, who donate their spaces to hold these workshops.
I am already looking forward to new Girl's Learning Code workshops. I hope to set up a chapter down home in Lethbridge before the year is out. I know my nephew really enjoyed the workshop and is extremely interested in attending another, so I have hopes that the rest of the students enjoyed this one as much as he and I did.
There's all sorts of stories and reasons behind the lack of women in software development, and I'm not planning on debating which or how influential any of them are. I'll just pick one to start with here. We call it "the pipeline". It's really hard to increase the percentage of women in software development jobs, when the percentage of young women entering the field remains so ridiculously low.
Why is it ridiculously low?
Young women, and really before that, young girls, are convinced that programming is boring, where you are just locked up in a room with a computer pounding out code 24/7. That is such a narrow and really misleading look at the profession that it just breaks my heart. Good programmers need to understand, deeply, the fields related to what they are programming, in order to do a good job. Good software developers need to be people-persons, to work with the users/customers of their software, to determine their needs, and to help them solve problems that they never even realized they had.
But here's a good starting place: The share of women in computer science started falling at roughly the same moment when personal computers started showing up in U.S. homes in significant numbers. -- npr.org
The simple fact is women were programming long before boys, when it was thought that programming was a "clerical" type of skill. Once the boys figured out it was more important than that, they made certain to elbow the women out of the way, quick enough. Follow that up with some really good ad campaigns that make it clear that computers are for boys, and now we have a self-fulfilling prophesy of a male-dominated profession, because there are not enough women mentors, and there is a lack of young women even wanting to enter in the pipeline into the field of software development. So let's fix that at the very start.
Shouldn't computer science be like reading/writing/arithmetic? Get kids, really young kids, learning how to program. Have a progression of skills that are taught and practiced throughout their school years.
(Ok, there never were 3 R's so don't bug me about that 4th one, mmmk?)
We teach reading and writing and arithmetic right from the get-go in schools. But computers are part of the new literacy, so using computers, and TALKING to computers, and telling computers what to do is a basic skill that needs to be engendered right along with those other three.
Introduced at an early enough stage, it becomes "just something you do", and not something related to video games or logic skills or math skills or whatever reason people pick to assume that boys are good at it while girls are not.
I would also argue that programming is a "maker" skill, and kids love to make things. Programming is making something with your mind, in collaboration with the computer. There is a joy involved in creating something new. Kids feel that way about their art projects, why not about their programs? What I'd really love to see is Facebook and Pinterest & Instagram filling up with links to my friends' kids' programming projects, much like their art projects show up on your fridge now.
"Look at this neat thing my kid made"
Why don't we have this already?
I'm doing my part. In a couple of weeks, I'm teaching the Girls Learning Code Ruby Workshop. We can always use more mentors, which will help us get some of those girls OFF the waiting list, and into the class!
So here it is, the end of January. This marks exactly a year since my husband and I were "just checking out" the housing market in Lethbridge, Alberta and fell in love with our money-pit of a property. I have another whole post drafted on how we arrived at our decision to move, so I'll leave that to another time, and just talk about what we've discovered about our new-old home town in that year.
I grew up in Lethbridge, so I thought I knew a lot about this place. In the time since I left to go to university in Calgary, Lethbridge has grown a lot. It is over double the size it was when I left, with a population of over 93,000. It was, and remains, a university town, with both the University of Lethbridge and Lethbridge College now contributing 8600 and 4000 students respectively to the local population. That youthful influx each year gives the city a more modern vibe than I remember from my childhood.
Lethbridge also claims a more diversified economy than its' big sibling cities of Alberta. It's not as chained to the oil economy as Calgary and Red Deer, nor as government-bound as Edmonton. It is southern Alberta's commercial, distribution, financial and industrial centre. While in the past, Lethbridge's economy was primarily agricultural, the Economic Development Lethbridge (EDL) organization, created in 2002, has started to have a significant impact.
As an avid Twitter user, I started building my list of #yql people to follow after we committed to the move. In the fall, I stumbled across an EDL event called tec & mingle hosted by tecconnect. I had no idea that Lethbridge had it's own tech incubator. Nor that it was fast becoming a world-leader in geo-spatial technologies. There's even a Tier 3 data centre, owned and operated by BlackBridge Technologies.
tec & mingle was an interesting event, where we got to meet numerous members of the local tech community, and drool over interesting technologies like the UAV drones of Ventus Geospatial used to collect aerial imagery and perform 3D mapping. Spent some time chatting with Chris Rabl, a front-end developer with Autovance, and saw a demo of their interesting software product that is helping car dealerships streamline their financing options. And I got to run into old school friends, like Alan Schneider, who is now executive director of the Lethbridge Community Network, providing support for not-for-profits with IT and computer services.
While my husband and I may have had a few lingering doubts about leaving the big city, I have to say that those doubts have been completely laid to rest, and I am excited by the opportunities available in our new-old home town.
At long last, Core Data in Motion, my book that helps RubyMotion developers get up to speed with Core Data in their RubyMotion projects, is complete.
So, what is RubyMotion? RubyMotion enables you to write cross-platform applications for iOS, Android, and OS X in Ruby. Instead of using the painfully verbose syntax of Objective-C, or taking a chance on the not-quite-ready-for-production Swift language, you can use the programming language that was designed to make programming fun to develop your iOS applications.
And what is Core Data? Core Data is to iOS and OS X development what ActiveRecord is to Rails. It solves all the hard problems involved in your data stack. To quote Drew Crawford
If you are saving more than 3 objects to disk without linking to CoreData.framework, you’re doing it wrong.
This final chapter of Core Data in Motion is an epic look at the available gems and CocoaPods that can simplify and streamline your Core Data code. It weighs in at more that double the size of any of the other chapters in the book.
My reviewers have given fantastic feedback on this chapter, and I know you will find it extremely helpful, when trying to figure out which gem or CocoaPod will be most useful to speed along the development of your application.
Each gem is demonstrated, as I walk you through the process of transforming the base Core Data API's used in the book's sample project, into the gem's specific API. I also discuss the problems and issues I discovered along the way, so you can see what happens, and avoid those problems in your project.
It's been a long time coming, but Core Data in Motion will definitely give you the boost into using Core Data that you need, and save you hours and days of investigation and frustration.