FLOSS Project Planets

KnackForge: How to update Drupal 8 core?

Planet Drupal - Sat, 2018-03-24 01:01
How to update Drupal 8 core?

Let's see how to update your Drupal site between 8.x.x minor and patch versions. For example, from 8.1.2 to 8.1.3, or from 8.3.5 to 8.4.0. I hope this will help you.

  • If you are upgrading to Drupal version x.y.z

           x -> is known as the major version number

           y -> is known as the minor version number

           z -> is known as the patch version number.

Sat, 03/24/2018 - 10:31
Categories: FLOSS Project Planets

Joey Hess: 12 to 24 volt house conversion

Planet Debian - Mon, 2017-06-26 23:44

Upgrading my solar panels involved switching the house from 12 volts to 24 volts. No reasonably priced charge controllers can handle 1 KW of PV at 12 volts.

There might not be a lot of people who need to do this; entirely 12 volt offgrid houses are not super common, and most upgrades these days probably involve rooftop microinverters and so would involve a switch from DC to AC. I did not find a lot of references online for converting a whole house's voltage from 12V to 24V.

To prepare, I first checked that all the fuses and breakers were rated for > 24 volts. (Actually, > 30 volts because it will be 26 volts or so when charging.) Also, I checked for any shady wiring, and verified that all the wires I could see in the attic and wiring closet were reasonably sized (10AWG) and in good shape.

Then I:

  1. Turned off every light, unplugged every plug, pulled every fuse and flipped every breaker.
  2. Rewired the battery bank from 12V to 24V.
  3. Connected the battery bank to the new charge controller.
  4. Engaged the main breaker, and waited for anything strange.
  5. Screwed in one fuse at a time.

The house used all fluorescent lights, and they have ballasts rated for only 12V. While they work at 24V, they might blow out sooner or overheat. In fact one died this evening, and while it was flickering before, I suspect the 24V did it in. It makes sense to replace them with more efficient LED lights anyway. I found some 12-24V DC LED lights for regular screw-in (edison) light fixtures. Does not seem very common; Amazon only had a few models and they shipped from China.

Also, I ordered a 15 foot long, 300 LED strip light, which runs on 24V DC and has an adhesive backing. Great stuff -- it can be cut to different lengths and stuck anywhere. I installed some underneath the cook stove hood and the kitchen cabinets, which didn't have lights before.

Similar LED strips are used in some desktop lamps. My lamp was 12V only (barely lit at 24V), but I was able to replace its LED strip, upgrading it to 24V and three times as bright.

(Christmas lights are another option; many LED christmas lights run on 24V.)


My Lenovo laptop's power supply that I use in the house is a vehicle DC-DC converter, and is rated for 12-24V. It seems to be running fine at 26V, did not get warm even when charging the laptop up from empty.

I'm using buck converters to run various USB powered (5V) ARM boxes such as my sheevaplug. They're quarter sized, so fit anywhere, and are very efficient.

My satellite internet receiver is running with a large buck converter, feeding 12V to an inverter, feeding to a 30V DC power supply. That triple conversion is inneficient, but it works for now.

The ceiling fan runs on 24V, and does not seem to run much faster than on 12V. It may be rated for 12-24V. Can't seem to find any info about it.

The radio is a 12V car radio. I used a LM317 to run it on 24V, to avoid the RF interference a buck converter would have produced. This is a very inneficient conversion; half of the power is wasted as heat. But since I can stream internet radio all day now via satellite, I'll not use the FM radio very often.

Fridge... still running on propane for now, but I have an idea for a way to build a cold storage battery that will use excess power from the PV array, and keep a fridge at a constant 34 degrees F. Next home improvement project in the queue.

Categories: FLOSS Project Planets

Benjamin Mako Hill: Learning to Code in One’s Own Language

Planet Debian - Mon, 2017-06-26 21:00

I recently published a paper with Sayamindu Dasgupta that provides evidence in support of the idea that kids can learn to code more quickly when they are programming in their own language.

Millions of young people from around the world are learning to code. Often, during their learning experiences, these youth are using visual block-based programming languages like Scratch, App Inventor, and Code.org Studio. In block-based programming languages, coders manipulate visual, snap-together blocks that represent code constructs instead of textual symbols and commands that are found in more traditional programming languages.

The textual symbols used in nearly all non-block-based programming languages are drawn from English—consider “if” statements and “for” loops for common examples. Keywords in block-based languages, on the other hand, are often translated into different human languages. For example, depending on the language preference of the user, an identical set of computing instructions in Scratch can be represented in many different human languages:

Examples of a short piece of Scratch code shown in four different human languages: English, Italian, Norwegian Bokmål, and German.

Although my research with Sayamindu Dasgupta focuses on learning, both Sayamindu and I worked on local language technologies before coming back to academia. As a result, we were both interested in how the increasing translation of programming languages might be making it easier for non-English speaking kids to learn to code.

After all, a large body of education research has shown that early-stage education is more effective when instruction is in the language that the learner speaks at home. Based on this research, we hypothesized that children learning to code with block-based programming languages translated to their mother-tongues will have better learning outcomes than children using the blocks in English.

We sought to test this hypothesis in Scratch, an informal learning community built around a block-based programming language. We were helped by the fact that Scratch is translated into many languages and has a large number of learners from around the world.

To measure learning, we built on some of our our own previous work and looked at learners’ cumulative block repertoires—similar to a code vocabulary. By observing a learner’s cumulative block repertoire over time, we can measure how quickly their code vocabulary is growing.

Using this data, we compared the rate of growth of cumulative block repertoire between learners from non-English speaking countries using Scratch in English to learners from the same countries using Scratch in their local language. To identify non-English speakers, we considered Scratch users who reported themselves as coming from five primarily non-English speaking countries: Portugal, Italy, Brazil, Germany, and Norway. We chose these five countries because they each have one very widely spoken language that is not English and because Scratch is almost fully translated into that language.

Even after controlling for a number of factors like social engagement on the Scratch website, user productivity, and time spent on projects, we found that learners from these countries who use Scratch in their local language have a higher rate of cumulative block repertoire growth than their counterparts using Scratch in English. This faster growth was despite having a lower initial block repertoire. The graph below visualizes our results for two “prototypical” learners who start with the same initial block repertoire: one learner who uses the English interface, and a second learner who uses their native language.

Summary of the results of our model for two prototypical individuals.

Our results are in line with what theories of education have to say about learning in one’s own language. Our findings also represent good news for designers of block-based programming languages who have spent considerable amounts of effort in making their programming languages translatable. It’s also good news for the volunteers who have spent many hours translating blocks and user interfaces.

Although we find support for our hypothesis, we should stress that our findings are both limited and incomplete. For example, because we focus on estimating the differences between Scratch learners, our comparisons are between kids who all managed to successfully use Scratch. Before Scratch was translated, kids with little working knowledge of English or the Latin script might not have been able to use Scratch at all. Because of translation, many of these children are now able to learn to code.

This blog post and the work that it describes is a collaborative project with Sayamindu Dasgupta. Sayamindu also published a very similar version of the blog post in several places. Our paper is open access and you can read it here. The paper was published in the proceedings of the ACM Learning @ Scale Conference. We also recently gave a talk about this work at the International Communication Association’s annual conference. We received support and feedback from members of the Scratch team at MIT (especially Mitch Resnick and Natalie Rusk), as well as from Nathan TeBlunthuis at the University of Washington. Financial support came from the US National Science Foundation.

Categories: FLOSS Project Planets

Bryan Pendleton: Those were the days ...

Planet Apache - Mon, 2017-06-26 20:53

A dear colleague of mine tracked down this wonderful picture of me with one of my favorite engineering teams:

How wonderful it was to have such brilliant co-workers to learn from!

If, in some magical way, 56-year-old Bryan could go back 23 years and talk to 33-year-old Bryan, what would I say?

Maybe something like:

Pay attention, keep listening, and work hard: you've still got a LOT left to learn.

Of course, that's just as true now.

Hmmm, maybe I just got some words of wisdom from 79-year-old Bryan, far off in the future?

As for the picture, as I recall, we were looking for a theme for a team picture, and Nat and Brian both happened to be wearing their leather coats that day, and so somebody (Rich? Ken?) suggested we all get our coats and sunglasses and "look tough". So we did...

Categories: FLOSS Project Planets

Justin Mason: Links for 2017-06-26

Planet Apache - Mon, 2017-06-26 19:58
Categories: FLOSS Project Planets

Niels Thykier: debhelper 10.5.1 now available in unstable

Planet Debian - Mon, 2017-06-26 17:59

Earlier today, I uploaded debhelper version 10.5.1 to unstable.  The following are some highlights compared to version 10.2.5:

  • debhelper now supports the “meson+ninja” build system. Kudos to Michael Biebl.
  • Better cross building support in the “makefile” build system (PKG_CONFIG is set to the multi-arched version of pkg-config). Kudos to Helmut Grohne.
  • New dh_missing helper to take over dh_install –list-missing/–fail-missing while being able to see files installed from other helpers. Kudos to Michael Stapelberg.
  • dh_installman now logs what files it has installed so the new dh_missing helper can “see” them as installed.
  • Improve documentation (e.g. compare and contrast the dh_link config file with ln(1) to assist people who are familiar with ln(1))
  • Avoid triggering a race-condition with libtool by ensuring that dh_auto_install run make with -j1 when libtool is detected (see Debian bug #861627)
  • Optimizations and parallel processing (more on this later)

There are also some changes to the upcoming compat 11

  • Use “/run” as “run state dir” for autoconf
  • dh_installman will now guess the language of a manpage from the path name before using the extension.


Filed under: Debhelper, Debian
Categories: FLOSS Project Planets

Joey Hess: DIY solar upgrade complete-ish

Planet Debian - Mon, 2017-06-26 17:44

Success! I received the Tracer4215BN charge controller where UPS accidentially-on-purpose delivered it to a neighbor, and got it connected up, and the battery bank rewired to 24V in a couple hours.

Here it's charging the batteries at 220 watts, and that picture was taken at 5 pm, when the light hits the panels at nearly a 90 degree angle. Compare with the old panels, where the maximum I ever recorded at high noon was 90 watts. I've made more power since 4:30 pm than I used to be able to make in a day! \o/

Categories: FLOSS Project Planets

Damián Avila: Trading logbook update 3

Planet Python - Mon, 2017-06-26 17:29

OK, I have run my models again and it was time to enter the market.

Early today, I opened two positions:

Read more… (1 min remaining to read)

Categories: FLOSS Project Planets

Alexander Wirt: Stretch Backports available

Planet Debian - Mon, 2017-06-26 17:00

With the release of stretch we are pleased to open the doors for stretch-backports and jessie-backports-sloppy. \o/

As usual with a new release we will change a few things for the backports service.

What to upload where

As a reminder, uploads to a release-backports pocket are to be taken from release + 1, uploads to a release-backports-sloppy pocket are to be taken from release + 2. Which means:

Source Distribution Backports Distribution Sloppy Distribution buster stretch-backports jessie-backports-sloppy stretch jessie-backports - Deprecation of LTS support for backports

We started supporting backports as long as there is LTS support as an experiment. Unfortunately it didn’t worked, most maintainers didn’t wanted to support oldoldstable-backports (squeeze) for the lifetime of LTS. So things started to rot in squeeze and most packages didn’t received updates. After long discussions we decided to deprecate LTS support for backports. From now on squeeze-backports(-sloppy) is closed and will not receive any updates. Expect it to get removed from the mirrors and moved to archive in the near future.

BSA handling

We - the backports team - didn’t scale well in processing BSA requests. To get things better in the future we decided to change the process a little bit. If you upload a package which fixes security problems please fill out the BSA template and create a ticket in the rt tracker (see https://backports.debian.org/Contribute/#index3h2 for details).

Stretching the rules

From time to time its necessary to not follow the backports rules, like a package needs to be in testing or a version needs to be in Debian. If you think you have one of those cases, please talk to us on the list before upload the package.


Thanks have to go out to all people making backports possible, and that includes up front the backporters themself who do upload the packages, track and update them on a regular basis, but also the buildd team making the autobuilding possible and the ftp masters for creating the suites in the first place.

We wish you a happy stretch :) Alex, on behalf of the Backports Team

Categories: FLOSS Project Planets

Acquia Developer Center Blog: Decoupling Drupal with Waterwheel for Ember and React

Planet Drupal - Mon, 2017-06-26 16:21

The Waterwheel ecosystem paves the way for non-Drupal developers to use decoupled Drupal as a headless back end without having to learn a lick of Drupal or PHP. Now, the Waterwheel team is excited to release several new projects that benefit developers developing JavaScript applications built in Ember and React.

Tags: acquia drupal planet
Categories: FLOSS Project Planets

Daemons and friendly Ninjas

Planet KDE - Mon, 2017-06-26 16:19

There’s quite a lot of software that uses CMake as a (meta-)buildsystem. A quick count in the FreeBSD ports tree shows me 1110 ports (over a thousand) that use it. CMake generates buildsystem files which then direct the actual build — it doesn’t do building itself.

There are multiple buildsystem-backends available: in regular usage, CMake generates Makefiles (and does a reasonable job of producing Makefiles that work for GNU Make and for BSD Make). But it can generate Ninja, or Visual Studio, and other buildsystem files. It’s quite flexible in this regard.

Recently, the KDE-FreeBSD team has been working on Qt WebEngine, which is horrible. It contains a complete Chromium and who knows what else. Rebuilding it takes forever.

But Tobias (KDE-FreeBSD) and Koos (GNOME-FreeBSD) noticed that building things with the Ninja backend was considerably faster for some packages (e.g. Qt WebEngine, and Evolution data-thingy). Tobias wanted to try to extend the build-time improvements to all of the CMake-based ports in FreeBSD, and over the past few days, this has been a succes.

Ports builds using CMake now default to using Ninja as buildsystem-backend.

Here’s a bitty table of build-times. These are one-off build times, so hardly scientifically accurate — but suggestive of a slight improvement in build time.

Name Size GMake Ninja liblxt 50kB 0:32 0:31 llvm38 1655kB * 19:43 musescore 47590kB 4:00 3:54 webkit2-gtk3 14652kB 44:29 37:40

Or here’s a much more thorough table of results from tcberner@, who did 5 builds of each with and without ninja. I’ve cut out the raw data, here are just the average-of-five results, showing usually a slight improvement in build time with Ninja.

Name av make av ninj Delta D/Awo compiler-rt 00:08 00:07 -00:01 -14% openjpeg 00:06 00:07 +00:01 +17% marble 01:57 01:43 -00:14 -11% uhd 01:49 01:34 -00:15 -13% opencacscade 04:08 03:23 -00:45 -18% avidemux 03:01 02:49 -00:12 – 6% kdevelop 01:43 01:33 -00:10 – 9% ring-libclient 00:58 00:53 -00:05 – 8%

Not everything builds properly with Ninja. This is usually due to missing dependencies that CMake does not discover; this shows up when foo depends on bar but no rule is generated for it. Depending on build order and speed, bar may be there already by the time foo gets around to being built. Doxygen showed this, where builds on 1 CPU core were all fine, but 8 cores would blow up occasionally.

In many cases, we’ve gone and fixed the missing implicit dependencies in ports and upstreams. But some things are intractable, or just really need GNU Make. For this, the FreeBSD ports infrastructure now has a knob attached to CMake for switching a port build to GNU Make.

  • Normal: USES=cmake
  • Out-of-source: USES=cmake:outsource
  • GNU Make: USES=cmake:noninja gmake
  • OoS, GMake: USES=cmake:outsource,noninja gmake
  • Bad: USES=cmake gmake

For the majority of users, this has no effect, but for our package-building clusters, and for KDE-FreeBSD developers who build a lot of CMake-buildsystem software in a day it may add up to an extra coffee break. So I’ll raise a shot of espresso to friendship between daemons and ninjas.

(Image credits: Beastie by Marshall Kirk McKusick on FreeBSD.org, Ninja by irkeninvaderkit on deviantart)

Categories: FLOSS Project Planets

Weekly Python Chat: collections.Counter

Planet Python - Mon, 2017-06-26 14:00

How should you count the number of times each thing occurs in a list? There are a lot of ways to solve this problem, but the most Python is often to use Counter.

Let's talk about different ways of counting things in a list, including Counter!

Categories: FLOSS Project Planets

Jonathan Dowland: Coming in from the cold

Planet Debian - Mon, 2017-06-26 12:18

I've been using a Mac day-to-day since around 2014, initially as a refreshing break from the disappointment I felt with GNOME3, but since then a few coincidences have kept me on the platform. Something happened earlier in the year that made me start to think about a move back to Linux on the desktop. My next work hardware refresh is due in March next year, which gives me about nine months to "un-plumb" myself from the Mac ecosystem. From the top of my head, here's the things I'm going to have to address:

  • the command modifier key (⌘). It's a small thing but its use on the Mac platform is very consistent, and since it's not used at all within terminals, there's never a clash between window management and terminal applications. Compared to the morass of modifier keys on Linux, I will miss it. It's possible if I settle on a desktop environment and spend some time configuring it I can get to a similarly comfortable place. Similarly, I'd like to stick to one clipboard, and if possible, ignore the select-to-copy, middle-click-to-paste one entirely. This may be an issue for older software.

  • The Mac hardware trackpad and gestures are honestly fantastic. I still have some residual muscle memory of using the Thinkpad trackpoint, and so I'm weaning myself off the trackpad by using an external thinkpad keyboard with the work Mac, and increasingly using a x61s where possible.

  • SizeUp. I wrote about this in useful mac programs. It's a window management helper that lets you use keyboard shortcuts to move move and resize windows. I may need something similar, depending on what desktop environment I settle on. (I'm currently evaluating Awesome WM).

  • 1Password. These days I think a password manager is an essential piece of software, and 1Password is a very, very good example of one. There are several other options now, but sadly none that seem remotely as nice as 1Password. Ryan C Gordon wrote 1pass, a Linux-compatible tool to read a 1Password keychain, but it's quite raw and needs some love. By coincidence that's currently his focus, and one can support him in this work via his Patreon.

  • Font rendering. Both monospace and regular fonts look fantastic out of the box on a Mac, and it can be quite hard to switch back and forth between a Mac and Linux due to the difference in quality. I think this is a mixture of ensuring the font rendering software on Linux is configured properly, but also that I install a reasonable selection of fonts.

I think that's probably it: not a big list! Notably, I'm not locked into iTunes, which I avoid where possible; Apple's Photo app (formerly iPhoto) which is a bit of a disaster; nor Time Machine, which is excellent, but I have a backup system for other things in place that I can use.

Categories: FLOSS Project Planets

Shopkick Tech Blog: Seashore: A Collection of Shell Abstractions

Planet Python - Mon, 2017-06-26 11:45

For many months now, Shopkick has been undergoing an infrastructure revolution. Modern infrastructure means automation, and we find ourselves automating UNIX-like systems a lot. We like UNIX, because you can do amazingly powerful things in just a couple lines:

eval $(docker-machine env default) docker run --rm quay.io/manylinux1 /opt/python/cp27mu/bin/python --version

While we like UNIX, we love Python. Unfortunately, the equivalent Python code gets quite a bit heavier using only the standard library. First we would have to manually parse the output from docker-machine env, and then write a long subprocess.check_call([...]).

Is it possible to have our UNIX cake and elegantly eat it in Python? We want the formality of Python, with its ability to handle, say, file names with spaces in them and the ease of writing command-lines in shell. And can we do even better, and generate code that is amenable to unit testing, something which the UNIX shell provides no straightforward facility?

We certainly think so!

Just in time for summer, Seashore is a collection of elegant shell abstractions with an eye toward brevity and testability.

Using Seashore, the code above can be rewritten as:

from seashore import Executor, Shell, NO_VALUE xctr = Executor(Shell()) dm_xctr = xctr.in_docker_machine('default') version = dm_xctr.docker.run( 'quay.io/manylinux1', '/opt/python/cp27-cp27mu/bin/python', '--version', remove=NO_VALUE).batch()[0].strip() print("version is {}".format(version))

Since all of the low-level work of running a command line is done in Shell(), it is reasonably easy to convert this into unit-testable code:

# python_version.py from seashore import Executor, Shell, NO_VALUE def get_python_27_version(shell=None): xctr = Executor(shell or Shell()) dm_xctr = xctr.in_docker_machine('default') version = dm_xctr.docker.run( 'quay.io/manylinux1', '/opt/python/cp27-cp27mu/bin/python', '--version', remove=NO_VALUE).batch()[0].strip() return version

Now, we can unit test with something along the lines of

import unittest, mock import python_version class TestPythonVersion(unittest.TestCase): def test_basic(self): shell = mock.Mock() def side_effect(cmd, **kwargs): if cmd[0] == 'docker-machine': return SOMETHING_THAT_LOOKS_LIKE_DOCKER_MACHINE_OUTPUT, '' elif cmd[0] == 'docker': return '2.7.1242', '' shell.batch.side_effect = side_effect version = python_version.get_python_27_version(shell) self.assertEquals(version, '2.7.1242') # Assert that shell.batch was called with the right arguments

Seashore has native support for common Python and Python-adjacent tools, including git, pip, virtualenv, conda, docker, and more! Plus, it can be easily extended to support all your automation needs.

Seashore is available on GitHub and PyPI, where it's released under the MIT license.

Documentation is available on Read the Docs. Development is all public, and very active right now. With seashore already being used in production, all issues and pull requests are more than welcome!

Seashore is just the first of many Shopkick open-source releases we hope to bring you here on tech.shopkick.com. Be sure to subscribe for more!

Categories: FLOSS Project Planets

Caktus Consulting Group: 5 Ways to Deploy Your Python Web App in 2017 (PyCon 2017 Must-See Talk 4/6)

Planet Python - Mon, 2017-06-26 09:30

Part four of six in the 2017 edition of our annual PyCon Must-See Series, highlighting the talks our staff especially loved at PyCon. While there were many great talks, this is our team's shortlist.

I went into Andrew T Baker’s talk on deploying Python applications with some excitement about learning some new deployment methods. I had no idea that Andrew was going to deploy a simple “Hello World” app live, in 5 different ways!

  1. First up, Andrew used ngrok to expose localhost running on his machine to the web. I’ve used ngrok before to share with QA, but never thought about using it to share with a client. Interesting!

  2. Heroku was up next with a gunicorn Python web app server, with a warning that scaling is costly after the one free app per account.

  3. The third deploy was “Serverless” with an example via AWS Lambda, although many other serverless options exist.

  4. The next deploy was described as the way most web shops deploy, via virtual machines. The example deploy was done over the Google Cloud Platform, but another popular method for this is via Amazon EC2. This method is fairly manual, Andrew explained, with a need to Secure Shell (SSH) into your server after you spin it up.

  5. The final deploy was done via Docker with a warning that it is still fairly new and there isn't as much documentation available.

I am planning to rewatch Andrew’s talk and follow along on my machine. I’m excited to see what I can do.

Categories: FLOSS Project Planets

Doug Hellmann: decimal — Fixed and Floating Point Math — PyMOTW 3

Planet Python - Mon, 2017-06-26 09:00
The decimal module implements fixed and floating point arithmetic using the model familiar to most people, rather than the IEEE floating point version implemented by most computer hardware and familiar to programmers. A Decimal instance can represent any number exactly, round up or down, and apply a limit to the number of significant digits. Read … Continue reading decimal — Fixed and Floating Point Math — PyMOTW 3
Categories: FLOSS Project Planets

Mike Driscoll: PyDev of the Week: David Wolever

Planet Python - Mon, 2017-06-26 08:30

This week we welcome David Wolever (@wolever) as our PyDev of the Week. David is the co-founder of PyCon Canada and Akindi.com – a small company that’s making multiple-choice bubble sheet tests a little bit less terrible. He is also the author of the nose-parameterized project and the pprint++ project. You can also check out what other projects he contributes to on Github. Let’s take a few moments to get to know David!

Can you tell us a little about yourself (hobbies, education, etc):

I’m a long-time Python fan and startup founder from Toronto, Canada. I dropped out of software engineering at the University of Toronto when I realized that I was interested in building software, not proving runtime bounds of graph search algorithms (although I’m incredibly grateful to the people who do enjoy that), and I’ve been working with small startups ever since.

I’m the CTO of my company, Akindi, makes Scantron-style multiple choice bubbles sheets a little bit less terrible.

In 2012 some friends and I started PyCon Canada, and I’m incredibly excited that it’s going to be held in Montréal this year (get your tickets now, because they’re going to sell out: https://pycon.ca)

Outside of computers, I’m really into knots (top three: alpine butterfly, jug sling hitch, chain sinnet) and motorcycling.

I tweet at https://twitter.com/wolever

Why did you start using Python?

I started using Python around 2003 to hack on an open source curses-based MSN Messenger client called Pebrot

What other programming languages do you know and which is your favorite?

I write quite a bit of JavaScript at my day job, and I’m embarrassingly proficient in Bash. I’ve also written a nontrivial amount of code in C, C++, PHP, and Go.

My favourite language, though, is SQL. I take an unhealthy amount of joy from working with SQL (and, specifically, Postgres).

The next language I invest in will be something with a strong, static, type system. Maybe Flow? TypeScript? I’m not sure yet. But I’m tired of all the time I waste on issues the computer should have detected for me.

What projects are you working on now?

My main project is my company, Akindi. Our product is a Scantron-style multiple-choice bubble sheet grading system that’s less terrible than anything else on the market. (Un)fortunately we’ve grown enough that I don’t get to do much coding day-to-day, though.

As far as open source projects go, I’ve got a couple little ones that I’m proud of:

  • git-blast, which shows git commits sorted by last commit date
  • parameterized, a parameterized testing library that works with every testing framework
  • pprintpp, a drop-in replacement for the pprint module, but it’s actually pretty

Which Python libraries are your favorite (core or 3rd party)?

ohh… that’s a tricky question. A few that come to mind, though:

  • gevent: I love gevent’s implementation, and the API it exposes is easily the best concurrency API that exists for Python. It’d be awesome if there was a similar API for threading and multiprocessing.
  • pathlib: is really nifty, and I haven’t regretted using it yet.
  • pandas: oh gee is Pandas ever great. I smile every time I get to use it.
  • pdb++: I love debugging with pdb, and pdb++ makes it much nicer

Where do you see Python going as a programming language?

That’s a fantastic question, and my honest answer is that I’ve got no idea.

I hope, though, that the effort to build clean, usable APIs will continue. Python’s APIs are steadily getting better… but I still have to check StackOverflow each time I need to convert a datetime to a timestamp or visa versa.

What is your take on the current market for Python programmers?

It’s annoying! Because everyone wants to hire them, which is making really difficult for me to hire them

Categories: FLOSS Project Planets

EuroPython: EuroPython 2017: Please configure your tickets

Planet Python - Mon, 2017-06-26 08:22

The EuroPython website supports buying tickets for other people (friends, colleagues, etc.). As a result, it is necessary to assign the tickets you buy to either yourself or someone else. The assignment process is explained below.

Please tell us your preferences

The reason we’re interested in you applying this configuration as soon as possible, is that the tickets include a number of preferences which we need to know about in order to properly prepare the conference.

When assigning tickets you will fill some fields, telling us your t-shirt size and cut (women or men style) and your diet preferences. We need this information to adjust the t-shirt and catering orders.

How to assign tickets to attendees

First you need to log in and go to your profile and, if you already bought your tickets, you will see something similar to this. Click on View your tickets.

After you have navigated to the tickets, we need you to assign the ticket: simply hover over the ticket and you will see two options. Please select, if the ticket is for you or for someone else.

Remember: Before assigning the ticket the other persons, these must be registered on the website. Otherwise, the assignment won’t work.

If you have assigned the tickets to someone else, please let them know. The system will send out automatic emails, but it’s safer to send a separate email so that the information doesn’t get lost in a spam filter.

How to edit the fields of the tickets

After assigning the ticket, each attendee will need to fill out the ticket preferences using his/her profile page (don’t forget to click save to store the settings):

Some additional help for the preference form:

Tagline: This line will appear after you name. Be original!

Diet: Omnivorous, Vegetarian or Other (we’ll try to provide food for other diets as well)

Python experience: Whats your experience level with Python? You can also enter “no comment”, if you prefer not to make this information public.

Dates: Which days do you plan to attend. This is not binding in any way, it just helps us to better prepare for the conference.


EuroPython 2017 Team
EuroPython Society
EuroPython 2017 Conference

Categories: FLOSS Project Planets

Wesley Chun: Modifying events with the Google Calendar API

Planet Python - Mon, 2017-06-26 07:36
IntroductionIn an earlier post, I introduced Python developers to adding events to users' calendars using the Google Calendar API. However, while being able to insert events is "interesting," it's only half the picture. If you want to give your users a more complete experience, modifying those events is a must-have. In this post, you'll learn how to modify existing events, and as a bonus, learn how to implement repeating events too.

In order to modify events, we need the full Calendar API scope:
  • 'https://www.googleapis.com/auth/calendar'—read-write access to Calendar
Skipping the OAuth2 boilerplate, once you have valid authorization credentials, create a service endpoint to the Calendar API like this:
GCAL = discovery.build('calendar', 'v3',
http=creds.authorize(Http()))Now you can send the API requests using this endpoint.

Using the Google Calendar APIOur sample script requires an existing Google Calendar event, so either create one programmatically with events().insert() & save its ID as we showed you in that earlier post, or use events().list() or events().get() to get the ID of an existing event.

While you can use an offset from GMT/UTC, such as the GMT_OFF variable from the event insert post, today's code sample "upgrades" to a more general IANA timezone solution. For Pacific Time, it's "America/Los_Angeles". The reason for this change is to allow events that survive across Daylight Savings Time shifts. IOW, a dinner at 7PM/1900 stays at 7PM as we cross fall and spring boundaries. This is especially important for events that repeat throughout the year. Yes, we are discussing recurrence in this post too, so it's particularly relevant.

Modifying calendar eventsIn the other post, the EVENT body constitutes an "event record" containing the information necessary to create a calendar entry—it consists of the event name, start & end times, and invitees. That record is an API resource which you created/accessed with the Calendar API via events().insert(). (What do you think the "R" in "URL" stands for anyway?!?) The Calendar API adheres to RESTful semantics in that the HTTP verbs match the actions you perform against a resource.

In today's scenario, let's assume that dinner from the other post didn't work out, but that you want to reschedule it. Furthermore, not only do you want to make that dinner happen again, but because you're good friends, you've made a commitment to do dinner every other month for the rest of the year, then see where things stand. Now that we know what we want, we have a choice.

There are two ways to modifying existing events in Calendar:
  1. events().patch() (HTTP PATCH)—"patch" 1 or more fields in resource
  2. events().update() (HTTP PUT)—replace/rewrite entire resource
Do you just update that resource with events().patch() or do you replace the entire resource with events().update()? To answer that question, ask yourself, "How many fields am I updating?" In our case, we only want to change the date and make this event repeat, so PATCH is a better solution. If instead, you also wanted to rename the event or switch dinner to another set of friends, you'd then be changing all the fields, so PUT would be a better solution in that case.

Using PATCH means you're just providing the deltas between the original & updated event, so the EVENT body this time reflects just those changes:
TIMEZONE = 'America/Los_Angeles'
'start': {'dateTime': '2017-07-01T19:00:00', 'timeZone': TIMEZONE},
'end': {'dateTime': '2017-07-01T22:00:00', 'timeZone': TIMEZONE},
'recurrence': ['RRULE:FREQ=MONTHLY;INTERVAL=2;UNTIL=20171231']
}Repeating eventsSomething you haven't seen before is how to do repeating events. To do this, you need to define what’s known as a recurrence rule ("RRULE"), which answers the question of how often an event repeats. It looks somewhat cryptic but follows the RFC 5545 Internet standard which you can basically decode like this:
  • FREQ=MONTHLY—event to occur on a monthly basis...
  • INTERVAL=2—... but every two months (every other month)
  • UNTIL=20171231—... until this date
There are many ways events can repeat, so I suggest you look at all the examples at the RFC link above.

Finishing touchesFinally, provide the EVENT_ID and call events().patch():
e = GCAL.events().patch(calendarId='primary', eventId=EVENT_ID,
sendNotifications=True, body=EVENT).execute()
Keep in mind that in real life, your users may be accessing your app from their desktop or mobile devices, so you need to ensure you don't override an earlier change. In this regard, developers should use the If-Match header along with an ETag value to validate unique requests. For more information, check out the conditional modification page in the official docs.

The one remaining thing is to confirm on-screen that the calendar event was updated successfully. We do that by checking the return value—it should be an Event object with all the existing details as well as the modified fields:
*** %r event (ID: %s) modified:
Start: %s
End: %s
Recurring (rule): %s
''' % (e['summary'].encode('utf-8'), e['id'], e['start']['dateTime'],
e['end']['dateTime'], e['recurrence'][0]))
That's pretty much the entire script save for the OAuth2 boilerplate code we've explored previously. The script is posted below in its entirety, and if you add a valid event ID and run it, depending on the date/times you use, you'll see something like this:
$ python gcal_modify.py
*** 'Dinner with friends' event (ID: YOUR_EVENT_ID_STR_HERE) modified:
Start: 2017-07-01T19:00:00-07:00
End: 2017-07-01T22:00:00-07:00
Recurring (rule): RRULE:FREQ=MONTHLY;UNTIL=20171231;INTERVAL=2
It also works with Python 3 with one slight nit/difference being the "b" prefix on from the event name due to converting from Unicode to bytes:
*** b'Dinner with friends' event...

ConclusionNow you know how to modify events as well as make them repeat. To complete the example, below is the entire script for your convenience which runs on both Python 2 and Python 3 (unmodified!):
from __future__ import print_function
from apiclient.discovery import build
from httplib2 import Http
from oauth2client import file, client, tools

SCOPES = 'https://www.googleapis.com/auth/calendar'
store = file.Storage('storage.json')
creds = store.get()
if not creds or creds.invalid:
flow = client.flow_from_clientsecrets('client_secret.json', SCOPES)
creds = tools.run_flow(flow, store)
CAL = build('calendar', 'v3', http=creds.authorize(Http()))

TIMEZONE = 'America/Los_Angeles'
'start': {'dateTime': '2017-07-01T19:00:00', 'timeZone': TIMEZONE},
'end': {'dateTime': '2017-07-01T22:00:00', 'timeZone': TIMEZONE},
'recurrence': ['RRULE:FREQ=MONTHLY;INTERVAL=2;UNTIL=20171231']
e = GCAL.events().patch(calendarId='primary', eventId=EVENT_ID,
sendNotifications=True, body=EVENT).execute()

*** %r event (ID: %s) modified:
Start: %s
End: %s
Recurring (rule): %s
''' % (e['summary'].encode('utf-8'), e['id'], e['start']['dateTime'],
e['end']['dateTime'], e['recurrence'][0]))
You can now customize this code for your own needs, for a mobile frontend, a server-side backend, or to access other Google APIs. If you want to learn more about using the Google Calendar API, check out the following resources:

Categories: FLOSS Project Planets

Django Weekly: Django weekly - Optimisation Guide, Kubernetes, google authentication and more

Planet Python - Mon, 2017-06-26 05:59

Worthy Read
Django project optimization guide (part 1)This is the first part of a series about Django performance optimization. It will cover logging, debug toolbar, locust.io for testing, Silk etc.
Django vs FlaskThis analysis is a comparison of 2 python frameworks, Flask and Django. It discusses their features and how their technical philosophies impact software developers. It is based on my experience using both, as well as time spent personally admiring both codebases.
web framework
Is Your DevOps Pipeline Leaking?Gartner’s Recommendations for Long-Term Pipeline Success.
Getting started with translating a Django ApplicationAfter reading this article, you have a basic understanding of translating a Django app.
Kubernetes Health Checks in Django - By Ian LewisHealth checks are a great way to help Kubernetes help your app to have high availability, and that includes Django apps.
How web requests are processed in a typical Django application - By Arun RavindranIllustration of request processing in Django from browser to back.
Simple Google Authentication in Django - By Sahil JainHow to build a simple google authentication app on Django framework.
Celery 4 Periodic Task in Django - By Yehan DjoehartonoAutomation in Django is a developer dream. Tedious work such as creating database backup, reporting annual KPI, or even blasting email could be made a breeze. Through Celery?—?a well-known software in Python for delegating task?—?such action made possible.
Django For Beginners BookDjango For Beginners Book

django-admin-env-notice - 24 Stars, 0 ForkVisually distinguish environments in Django Admin. Based on great advice from post: 5 ways to make Django Admin safer by hakibenita.
Scrum - 0 Stars, 0 ForkNow work in a far more efficient and organized manner! The project allows users to list their tasks in a scrum order, monitor and update their progress.
django-base - 0 Stars, 0 ForkA Dockerized Django project template with NGINX and PostgreSQL ready to go
Categories: FLOSS Project Planets
Syndicate content