Maintaining a focus on fun and interactivity keeps students engaged and enthused while learning Java.
I consider myself extremely fortunate to be involved with Devoxx4Kids, a Not-for-Profit, 501(c)(3) registered organization in the U.S., whose goal is to deliver Science Technology Engineering Mathematics (STEM) workshops to kids at an early age around the world. We delivered over 40 workshops in the U.S. alone last year on topics ranging from Python, Scratch, and Minecraft modding to NAO robots, Raspberry Pi, Arduino, and Little Circuits. Globally, we’ve delivered over 350 workshops and connected with approximately 5,000 students, with over 30% girls. Attendees from these workshops often leave with unique and inspirational stories to share. Read more…
Python's simplicity makes it accessible to learners and teachers alike.
Download a free copy of Python in Education. Editor’s note: this is an excerpt from Python in Education, a free report written by Nicholas Tollervey.
I am going to answer a very simple question: which features of the Python language itself make it appropriate for education? This will involve learning a little Python and reading some code. But don’t worry if you’re not a coder! This chapter will hopefully open your eyes to how easy it is to learn Python (and thus, why it is such a popular choice as a teaching language).
When I write a to-do list on a piece of paper, it looks something like this:
Shopping Fix broken gutter Mow the lawn
This is an obvious list of items. If I wanted to break down my to-do list a bit further, I might write something like this:
Shopping: Eggs Bacon Tomatoes Fix broken gutter: Borrow ladder from next door Find hammer and nails Return ladder! Mow the lawn: Check lawn around pond for frogs Check mower fuel level
Intuitively, we understand that the main tasks are broken down into sub-tasks that are indented underneath the main task to which they relate. This makes it easy to see, at a glance, how the tasks relate to each other.
What to expect at OSCON 2015.
Twenty years ago, open source was a cause. Ten years ago, it was the underdog. Today, it sits upon the Iron Throne ruling all it surveys. Software engineers now use open source frameworks, languages, and tools in almost all projects.
When I was putting together the program for OSCON with the other program chairs, it occurred to me that by covering “just” open source, we weren’t really leaving out all that much of the software landscape. It seems open source has indeed won, but let’s not gloat; let’s make things even better. Open source has made many great changes to software possible, but the spirit of the founding community goes well beyond code. Read more…
A step-by-step approach to using Swift with Objective-C.
If you’ve got an existing app written in Objective-C, migrating it into Swift is an excellent exercise for learning Swift, experimenting with Swift, and deciding whether to adopt Swift on a full-time basis. I’ve performed this migration with several real apps, so here are some tips culled from my actual experience.
You’re surely not going to translate all your code into Swift at once; you’re much more likely to translate one class at a time. As soon as you add a Swift file to your Objective-C app target, you’ve got a hybrid target: some classes are written in Swift, while other other classes are written in Objective-C. Thus, declarations in each language will need to be visible to the other language. Before you start, it’s a good idea to understand how this visibility works.
Recall that an Objective-C class declaration is conventionally spread over two files: a header file (.h) containing the
@interface section, and a code file (.m) containing the
@implementation section. If a .m file needs to know about a class, it imports the corresponding .h file.
Visibility of Swift and Objective-C to one another depends upon this convention: it works through .h files. There are two directions of visibility, and they must be considered separately.
Microservices optimize evolutionary change at a granular level.
We just finished the first O’Reilly Software Architecture Conference and the overwhelming most popular topic was microservices. Why all the hype about an architectural style?
Microservices are the first post-DevOps revolution architecture.
The DevOps revolution highlighted how much inadvertent friction an outdated operations mindset can cause, starting the move towards automating away manual tasks. By automating chores like machine provisioning and deployments, it suddenly became cheap to make changes that used to be expensive. Some architects properly viewed this new capability as a super power, and built architectures that fully embraced the operational aspects of their design. The Microservice architectural style prioritizes operational concerns as one of the key aspects of the architecture.
Microservice architectures borrow a design aesthetic from Domain Driven Design called the Bounded Context. A bounded context encapsulates all internal details of that domain and has explicit integration points with other bounded contexts. Microservice architectures reify the logical DDD bounded context into physical architecture. For example, it is common in microservice architectures for services that must persist data to own their database: members of the service team handle provisioning, backups, schema, migration, etc. In other words, in microservice architectures, the bounded context is also a physical context. But that also means that this service implementation isn’t coupled to any other team’s implementation, clearing the path for independent evolution. I recently published some writing about the recent realization that architecture is abstract until operationalized. In other words, until you have deployed an architecture and upgraded parts of it, you don’t fully understand it.
The O'Reilly Radar Podcast: Neal Ford on the changing role of software architects and the rise of microservices.
In this episode of the Radar Podcast, O’Reilly’s Mac Slocum sits down with Neal Ford, a software architect and meme wrangler at ThoughtWorks, to talk about the changing role of software architects. They met up at our recent Software Architecture Conference in Boston — if you missed the event, you can sign up to be notified when the Complete Video Compilation of all sessions and talks is available.
Slocum started the conversation with the basics: what, exactly, does a software architect do. Ford noted that there’s not a straightforward answer, but that the role really is a “pastiche” of development, soft skills and negotiation, and solving business domain problems. He acknowledged that the role historically has been negatively perceived as a non-coding, post-useful, ivory tower deep thinker, but noted that has been changing over the past five to 10 years as the role has evolved into real-world problem solving, as opposed to operating in abstractions:
“One of the problems in software, I think, is that you build everything on towers of abstractions, and so it’s very easy to get to the point where all you’re doing is playing with abstractions, and you don’t reify that back to the real world, and I think that’s the danger of this kind of ivory-tower architect. When you start looking at things like continuous delivery and continuous deployment, you have to take those operational concerns into account, and I think that is making the role of architect a lot more relevant now, because they are becoming much more involved in the entire software development ecosystem, not just the front edge of it.”