From macquigg at ece.arizona.edu Tue Jul 7 01:21:55 2015 From: macquigg at ece.arizona.edu (David MacQuigg) Date: Mon, 6 Jul 2015 16:21:55 -0700 Subject: [Edu-sig] Fairwell PyKata Message-ID: I just got a notice from Google that PyKata and a few other programs I developed using the Google App Engine, will no longer work unless I migrate these applications to their new High Replication Datastore. I took a quick look at that process, but it has been too many years, and I am too busy with my other activities to complete that process. So PyKata will die very soon, unless someone wants to take over as admin, and keep this website alive. You'll need to know Django and Google App Engine as well as Python. The plan, which I was never able to complete, was to make this website into a template that could be customized by anyone wanting to use it in their own teaching activities. The homepage would appear as unique to each school. Every teacher could have their own set of exercises, or use whatever they like of someone else's set. It's all under a Creative Commons license. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirby.urner at gmail.com Mon Jul 13 20:58:04 2015 From: kirby.urner at gmail.com (kirby urner) Date: Mon, 13 Jul 2015 11:58:04 -0700 Subject: [Edu-sig] Infrastructure Issues (typo + broken link + outta date info) Message-ID: (1) From our home page: More and more, Python is making inroads at all levels in education. Python offers an interactive environment in which to explore procedural, functional and object oriented approaches to problem solving. Its high level data structures and clear syntax make it an ideal first language, while the large number of existing libraries make it suitable to tackle almost any programming tasks. Slightly better grammar: any programming task. In the singular. "All tasks, any task". (2) Broken link: On our mailman front page: https://mail.python.org/mailman/listinfo/edu-sig the link to "edu-sig" home page: www.python.org/sigs/edu-sig/ fails and resolves instead to: www.python.org/community/sigs/ (link from mailman oughta be: www.python.org/community/sigs/current/edu-sig/ ) (3) I think the mailmain front page has wrong info re listownership, right? Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirby.urner at gmail.com Sun Jul 26 22:36:27 2015 From: kirby.urner at gmail.com (kirby urner) Date: Sun, 26 Jul 2015 13:36:27 -0700 Subject: [Edu-sig] trails through the ecosystem: language sequence Message-ID: Thinking of how I might design a robust computer science learning thread using today's open source tools. See caveats at the bottom. Python is oft circled as a great first language, but then what? From a practical standpoint, I'd say: leverage your Python to tackle a second OO language: Java (not JavaScript yet). Then leverage your Java, which need not be super polished, to tackle Clojure. That'll be a first LISP-family language and will start to formalize ground covered, making the concepts more clear. Pick up concurrency concepts here. Finally: back to Python i.e. take what you've learned on this circle tour to move into concurrency with Python if you wish, and with new fondness for a LISPish mindset. From here you're ready to branch to whatever your career calls for: more C family? More Apache stuff (Tomcat?). I'd say you've got even going on the language side with this point to start tackling DB world and its SQL/noSQL APIs. In sum: Python first Bridge to Java Tackle concurrency in Clojure (runs on JVM) back to Python, add more layers and polish === DB stuff: SQL + noSQL In between all this comes installation and simple sysadmin devops baby steps i.e. just learning the above interactively will bring an OS shell and perhaps an IDE into focus. Speaking of IDEs, that's a good place to introduce version control, where you can back end your code plane (screens) straight into some repository. Caveats: Note that I'm not talking about theory, not trying to outline general principles, hardware abstractions, parsing / compiling (back to theory of data structures, parse trees etc.). I'm imagining all that as content and/or background, while the above simply tracks an evolving skills set in terms of language and exposure to specific APIs. An alternative would be a more traditional LAMP stack approach, which still works as a thumbnail guide: L -- OS level on down to hardware A -- All lower level server processes e.g. httpd M -- Persistence Layer (keeping / updating state) P -- Application layer (hosted processes e.g. PHP's) i.e. it remains useful to break it down that way. Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirby.urner at gmail.com Sun Jul 26 22:53:14 2015 From: kirby.urner at gmail.com (kirby urner) Date: Sun, 26 Jul 2015 13:53:14 -0700 Subject: [Edu-sig] trails through the ecosystem: language sequence In-Reply-To: References: Message-ID: > I'd say you've got even going on the language > side with this point to start tackling DB world and > its SQL/noSQL APIs. "...got enough going"... Influential on this little essay was OSCON 2015, just finished. The big takeaway for me was big enterprises have finally bought in to the open source paradigm not just as an inventory of free tools but as a style of working that produces results. Management is retraining to make the internal development environment look almost the same as the public open source development world (same tools, same techniques, same small "two pizza teams" with committed committers). Instituting these practices, including sharing and maintaining one or more open source projects, as a way of throwing one's hat in the ring, is not just a way of improving inhouse productivity but of way attracting a productive brand of geek, the kind used to working with these tools to begin with. So we had Walmart Labs (first time), standardizing on Node.js + a lot of noSQL (e.g. Cassandra and Mongo), and PayPal (again), which is all about Apache Inside (talking the whole ecosystem of Apache Foundation projects, a lot of them ever more mission critical within the enterprise). PayPal calls in "InnerSource" i.e. using Open Source internally. Pictures: https://www.flickr.com/photos/kirbyurner/albums/72157653861631353/page1 Kirby > > In sum: > > Python first > Bridge to Java > Tackle concurrency in Clojure (runs on JVM) > back to Python, add more layers and polish > === > DB stuff: SQL + noSQL > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.engelberg at gmail.com Fri Jul 31 00:46:49 2015 From: mark.engelberg at gmail.com (Mark Engelberg) Date: Thu, 30 Jul 2015 15:46:49 -0700 Subject: [Edu-sig] trails through the ecosystem: language sequence In-Reply-To: References: Message-ID: On Sun, Jul 26, 2015 at 1:36 PM, kirby urner wrote: > I'd say: leverage your Python to tackle a second > OO language: Java (not JavaScript yet). Then > leverage your Java, which need not be super > polished, to tackle Clojure. That'll be a first > LISP-family language and will start to formalize > ground covered, making the concepts more > clear. Pick up concurrency concepts here. > > I think there are a lot of good paths, and I see the logic of what you propose. But as someone who uses both Clojure and Python, I'd like to remind you that Clojure introduces far more novelty than just the concurrency constructs. The biggest difference is that all the fundamental data structures are immutable, which lends itself to a rather elegant programming style that in most languages is only available for numbers and maybe strings. Once you embrace this, it really changes the way you code, and going back to a programming language that doesn't support immutable data well can feel painful. > Finally: back to Python i.e. take what you've > learned on this circle tour to move into concurrency > with Python if you wish, and with new fondness > for a LISPish mindset. > Yeah, as I point out above, in my experience most students don't want to go back to Python once they've embraced Clojure's way of doing things, because they can't employ those techniques well in Python. Also, Clojure is fairly opinionated about being anti-OO (at least, in the sense of the way people usually think about OO). So once you've drunk that Koolade, OO starts to feel kind of clunky and limiting as a way to organize programs. But that's probably a good thing. Even among mainstream programmers, OO is "on the way out", getting replaced by things like component entity systems, inheritance-less interfaces, traits, multimethods, etc. > > > Python first > Bridge to Java > Tackle concurrency in Clojure (runs on JVM) > back to Python, add more layers and polish > Right. My path for students looks more like: Racket first Bridge to Python and/or Java as a way to understand mainstream languages and paradigms and gain the ability to interact with the vast majority of code out there. With these three languages under their belt, they can probably read and write code in most languages reasonably well. Clojure as a language that fuses this all together: functional goodness similar to, and in some respects better than Racket, interoperation with Java and Javascript ecosystems. Other languages worth "dipping one's toe into" could be: C++ for low-level programming Javascript for mainstream client-side web programming Haskell for pure functional Scala for a functional/OO hybrid with an intricate type system and a robust dataflow ML to understand the style of pattern matching over abstract data types -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirby.urner at gmail.com Fri Jul 31 01:43:08 2015 From: kirby.urner at gmail.com (kirby urner) Date: Thu, 30 Jul 2015 16:43:08 -0700 Subject: [Edu-sig] trails through the ecosystem: language sequence In-Reply-To: References: Message-ID: Other languages worth "dipping one's toe into" could be: > C++ for low-level programming > Javascript for mainstream client-side web programming > Haskell for pure functional > Scala for a functional/OO hybrid with an intricate type system and a > robust dataflow > ML to understand the style of pattern matching over abstract data types > > > The paths you describe look excellent. I am in the low foothills of Clojure at the moment. Here's a blog about my first published Clojure program: http://controlroom.blogspot.com/2015/07/ramping-up.html The Clojure programmers on the Google Group are already telling me ways to refactor. Thanks for your insights. Next I have more followup based on my experiences at OSCON this year. edu-sig seems an appropriate venue. Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurner at oreillyschool.com Fri Jul 31 01:44:35 2015 From: kurner at oreillyschool.com (Kirby Urner) Date: Thu, 30 Jul 2015 16:44:35 -0700 Subject: [Edu-sig] OSCON: Lessons Learned Message-ID: OSCON: Lessons Learned by Kirby Urner, Mentor, O'Reilly School of Technology What the bigger enterprises are discovering, along with small and mid-sized, is that Open Source is not just end products, such as Perl and FireFox, but a way of working together to create those products, a supply chain, a process. In order to attract and keep the loyalty of engineers who work in the Open Source way, which has proved highly productive, the enterprise needs to not only use, but contribute to the Open Source commons. In supporting public projects, such as Asgard in the case of Netflix, OpenStack in the case of HP, Linux in the case of IBM, companies throw their hats in the ring, demonstrating they understand contributing source code is a way of earning good will, while reaping the benefits. Those who contribute quality code to the commons are seen as competent and powerful, using a currency engineers respect. Money is just data after all, whereas code is what harvests and controls data, moves it around in the cloud. Both Walmart Labs and Paypal, OSCON sponsors, provided eloquent testimony regarding their embracing of the Open Source way. Governments are not far behind, with the UK and US both sending heads of Digital Services departments to deliver complementary OSCON keynotes. Conway's Law states that organizations end up with systems reflective of their own internal communications. These days, staying nimble and on top of one's game, means adopting such Open Source practices as having "two pizza teams" (no bigger than might be fed on two pizzas) each tasked with maintaining and contributing features to smallish, well-defined products and services. Netflix sees the benefits of this design, with some teams committing new code at a relatively high rate compared to others. Loosely coupled services with managers highly aligned to company goals: that's a recipe for success. Monolithic proprietary applications, in contrast, tend to develop so many internal dependencies (including on a small cadre of indispensable programmers) that they encounter logjams in development. The whole enterprise bogs down. PayPal's name for adopting Open Source practices in-house is InnerSource. The core discovery is when engineers code on the assumption their code will be world readable, source open, they simply write better code. In practice, the sphere of projects supported by the Apache Foundation defines a ready-made commons. For PayPal, InnerSource means "Apache Inside" -- including such products as Spark and Tomcat, not just the famous web server. For WalMart Labs, the code base includes Node.js, Cassandra and Mongo. Engineers following the Open Source way do a better job at decoupling their projects, following the Unix philosophy of having many independent tools that each does something well-defined and discrete. The APIs are clearer that way. Innovation leverages the power of a community, including contributions from non-employees. When the license keeps the source open, the company partakes of greater positive synergies. Geniuses continue pouring their best thinking into vital enterprise assets, precisely because these assets are owned in common. No one may steal and possess exclusively of others: that's the hallmark of Free (as in liberated) Software. The Open Source approach is conducive to: (a) ownership by responsible teams, capable of responding to feedback (b) containerization and micro-services in the cloud, the most scalable and economical setting for enterprise computing (c) quick on-boarding of new talent, oft recruited from the community of contributers to one of these open projects a company values. The Open Source way includes using version control and such Agile techniques as test driven development (TDD is featured along our Python Track here at OST). As Allison Randal summarized recent history in her keynote: in the distant dino past of thirty years ago, a lot of people assumed Open Source was slated to always be playing catch up i.e. the "community edition" would always be second fiddle to what the closed source engineers were doing. That world view has been turned inside out in many critical domains, where open also means transparent, as in trusted, as well as best of breed. Who wants to build "the cloud" using tools owned and controlled by a tiny few? Open Source is a way to insure interoperability and hence long term profitability. Embracing the Open Source way is out of economic necessity, not just altruism. Open Source is about keeping control out of controlling hands and then competing (with "secret sauce" i.e. "value added") within that shared context. As it turns out, the business case for "keeping it open" is uber-compelling. OSCON's long list of big name sponsors is evidence of what's accepted as common wisdom these days: Open Source has won. -------------- next part -------------- An HTML attachment was scrubbed... URL: