I’ve wanted to write a tutorial on Kivy since hacking on Python 3 support during the dev sprints at Pycon 2013. My goal is to create a useful application that runs on multiple devices and highlights use of the KV Language to design user interfaces. I also want this multi-part series to describe end-to-end how to develop, maintain, and deploy a Kivy application. I intend it to be a model for newcomers to Kivy and even Python to develop their own cross platform or mobile applications in Python. Thus, it doesn’t just include code, but also deployment instructions and information on how to use the git version control system for basic history management.
Therefore, this tutorial series is written at a more basic level than a lot of my technical articles. My intended audience is new programmers who have some basic Python experience; perhaps having read The Python Tutorial and Learn Python The Hard Way, but possibly not the beginner-intermediate topics covered in my book, Python 3 Object Oriented Programming.
Having decided to write a tutorial, I needed to decide what kind of application to develop. This actually took quite a bit of thought. I decided on a Jabber client, as it has a user interface with reasonable complexity, and I am hoping that most of the difficult bits can be abstracted away into the SleekXMPP library. Finally, I had to settle on a name for the app; I chose Orkiv. I do not know why.
A blog isn’t the best platform for publishing a multi-part tutorial. I’ll include a Table Of Contents section in each part with references to all the other parts. Hopefully I’ll even keep it up to date!
Start by installing the following pre-requisites using standard operating system tools.
Python is the programming language and interpreter that Kivy programs are written in. Git is a version control system that we will use to track changes to our code. Virtualenv is a tool for creating isolated Python environments. Pip is an installer for installing python packages, in this case into the isolated virtualenv.
Note: Use of git is optional if you are more interested in learning to code than learning to manage a project. You are also welcome to use another version control system of your choice. At the level we will be working, the commands are virtually interchangeable.
Run the following commands in a terminal. (Note this tutorial was written using Arch Linux, and will probably work flawlessly on MacOS and other Linux distributions. However, you may need to do some experimenting to make Windows cooperate).
mkdir orkiv cd orkiv git init virtualenv -p python2.7 venv echo venv >> .gitignore echo "*.pyc" >> .gitignore git add .gitignore git commit -m "Create .gitignore file. Ignores compiled python files and venv." source venv/bin/activate
We’re creating a directory to hold our project and then initialize a git repository in there. We next create a virtualenv in a folder named venv. This folder will hold the isolated python files so that you can interact with Kivy without adding cruft to your system Python. I highly recommend creating a separate virtualenv for every project you work on.
Next, we set up a .gitignore file that tells git not to track certain files in our repository; in this instance all compiled python files, which end in .pyc, and the virtualenv directory we just created. We commit the changes to this file as our first commit in the git repository.
Finally, we “turn on” the virtualenv by sourcing its activate script. This essentially tells our shell to “use the isolated python for this project instead of system python”. When you are done working on this project, you should enter the command deactivate. When you come back to the project in the future, reenter the source venv/bin/activate command to turn on the isolated environment.
Note: If you maintain a lot of virtualenvs in a lot of different projects, as I do, you may be interested in a small script I wrote to facilitate switching between them.
Kivy depends on several Python libraries. Unfortunately, it does not have a setuptools-enabled setup.py to automatically install these dependencies into our virtualenv, so we have to do a little work ourselves. This takes a while, but if you copy paste these commands into your terminal, you should get lucky.
pip install cython pip install pygments pip install sphinx pip install pyglet pip install pillow # Because PIL is utter crap pip install pygame
Sadly, on Arch Linux, the last command, for pygame fails. I suspect it works fine on less bleeding edge operating systems, however, if you encounter an error about linux/videodev.h not existing, applying the Arch Linux patch to pygame may get you to the next step.
wget http://www.pygame.org/ftp/pygame-1.9.1release.tar.gz wget https://projects.archlinux.org/svntogit/packages.git/plain/trunk/pygame-v4l.patch?h=packages/python-pygame -O pygame-v4l.patch tar xf pygame-1.9.1release.tar.gz cd pygame-1.9.1release/ patch -Np1 -i ../pygame-v4l.patch python setup.py install cd .. rm pygame* -r
And now, you should finally be ready to install Kivy itself: This will take a while, so grab a smoothie while it runs:
pip install kivy python -c 'import kivy'
The latter command should output the kivy version (I’m working with 1.7.1). If it exits without failure, then you have successfully installed Kivy!
Create a directory to hold the application code:
mkdir orkiv
This directory will contain your Python and Kivy source files. Our goal is to be able to always create a zipfile from this directory and be able to run it using python orkiv.zip. As long as the required dependencies are installed on the target system (as described above), the program should run. It will therefore be nice and self-contained.
There is a relatively unknown feature of recent versions of Python to support this. If a directory or zipfile contains a __main__.py, that module will be executed if python is called with that directory or zipfile as an argument. First, create a file inside the new orkiv directory named __main__.py. Create a simple “hello world” in this file to test that
it’s working:
print("hello world!")
Now from the parent directory, run the command python orkiv. If you want to test it with a zipfile, try this:
cd orkiv zip ../orkiv.zip * cd .. python orkiv.zip
It is possible to code Kivy applications in pure Python, but in my opinion, it is much better to use the amazing KV Language to do layouts. The basic approach is to have a Python file (in our case __main__.py above) that contains the logic for the application, and a KV Language file that contains the layout information. The KV Language is very similar to Python and you can learn it as you go.
Lets start by removing the print statement from our __main__.py and replacing it with the most basic possible Kivy application:
from kivy.app import App
class Orkiv(App):
pass
Orkiv().run()
This simply imports a Kivy App class and creates a subclass of it using Python’s notoriously simple inheritance syntax. Inheritance is a useful feature of Object Oriented Programming that basically means that a class can be defined that has all the functionality of the parent class. In this case, since we didn’t add anything to the subclass, that’s ALL it has. However, the true beauty of inheritance is that we can add new properties and methods (functions attached to objects) to the subclass or even change the functionality that comes with the parent class (App). The best part is, we don’t really have to know what is going on inside the App, and can assume the Kivy devs know what they are doing.
It doesn’t even add anything to the subclass! Then it instantiates an instance of that subclass and calls the run() method on the newly created object.
If you run python kivy with the new code saved, you’ll see an empty window pop up.
As far as boilerplate goes, that’s pretty damn concise, don’t you think? The amazing thing is that we can start laying out KV Language widgets in a separate file without touching this boilerplate at all! Don’t believe me? Try saving the following as orkiv/orkiv.kv:
Label:
text: "hello world"
Now if you run python orkiv, you should see the “hello world” label centered in the window that pops up. It’s almost like magic, and if you’re like me, you’re probably wondering how that’s even possible.
When you create a subclass of a kivy.app.App, it introspects the name of the new class (we named it Orkiv). Then it looks for a file in the same directory that follows these rules:
.kv extensionThe Kivy documentation would have named the class OrkivApp and still used the orkiv.kv filename. Personally, I don’t see the redundant need to add App to the class name, since the inheritance structure clearly indicates that Orkiv is a App.
We’ll be working with the Kivy Language a lot as we proceed through each part of this tutorial. You’ll soon see that it’s possible to do more, a lot more, than add a label to a window!
At this point, you’ve created a logical related set of changes that are in a working state. I want to encourage you to experiment with these files, maybe change the contents of the label, try a different application and KV Language filename, or see if you can figure out how to group two labels into a single layout. But before doing that, you should record this known state that your repository is currently in so it’s easy to get back to. That way, you can be free to explore without fear of getting completely lost; you’ll always have a path straight back to your current state. You can do that from the command line using git:
git add orkiv/ git commit -m "A basic Kivy boiler plate"
You just made a commit on the master branch in git. First you listed the changes you wanted to include in the commit (the entirety of every file in the new orkiv directory), then you told git to record the current state of those files forever. It is generally recommended that you only save consistent, known-to-be-working state on the master branch. For the purposes of this tutorial, I suggest that you only save the code you copied from the tutorial to the master branch, and do your other development on other branches.
Are you confused by what a branch is, exactly? Think of it like walking down a forest path in a national park. You are following signs for a marked trail; that’s this tutorial. As you walk, you see things that you want to remember, so you take a photo. That’s like making a commit on the master branch. However, you also see side paths that you would like to explore on your own. You can go down that path as far as you want, or even take other random paths without fear of getting lost. You can even take photos on those paths, knowing they won’t get mixed in with the photos from the main trail. Then when you want to return to the point where you left the main trail, you can magically teleport back to it (or indeed, to any of the other branches you walked down in your exploration).
You probably won’t be doing it for this tutorial, but the most import aspect of version control is that if you are in unmarked forest rather than a national park, you can walk down all the paths and decide which one you’re going to choose as the main path. You can even merge paths back into each other so that the photos (code commits) taken on each of them end up in the same final presentation.
Enough digressing! For your purposes, the first thing you should do is create a new branch in git:
git checkout -b my_exploration
You are now on a new branch named my_exploration (you can call each branch whatever you want, of course) that is exactly the same as the master branch as you last saw it. But you can make changes on that branch to your heart’s content; you can add and commit them as above if you want to remember them for later. When you’re ready to come back to the tutorial, you can use this command to return to the current state of the master branch:
git checkout master
From there, you could continue with the next part of the tutorial, or you could create a new branch and explore in a different direction.
I am maintaining my own version of the code developed in this tutorial at https://github.com/buchuki/orkiv/. However, it’s not likely to be the same as your repository, since I’m not making commits at the same time that I’m suggesting you make commits. Instead, my master branch contains a separate commit for each example in the tutorial. I also create git tags for each part of the tutorial so it’s fairly easy to see from commit history what was covered in each part. If you browse the Commit History you can see each example and how it evolved from top to bottom. You can view the list of tags here.
I don’t expect the collected parts of this tutorial to be big enough to publish as a book, so I’m hosting them for free here on my blog. If you like the tutorial and would like to see similar work published in the future, please support me. I hope to one day reduce my working hours at my day job to have more time to devote to open source development and technical writing. If you think this article was valuable enough that you would have paid for it, please consider thanking me in one or more of the following ways:
If you aren’t in the mood or financial position to help fund this work, at least share it on your favorite social platforms!
]]>I started with the nightly Haiku gcc2hybrid4 build, because it’s the easiest. I enjoy updating to the latest nightly. I installed it and looked for any signs of the usual regressions: video driver problems, sound card problems, network problems… When there is a regression, I find the commit that caused it and report it on the Haiku bug tracker, where the kind Haiku developers promptly fix it. It’s fun! But, alas, everything worked great.
I have a separate partition with the Be File System on it to store all my personal files. It makes installing the nightlies super simple.
I installed the latest version of Linux Mint, Linux Mint 15 Cinnamon x86_64. I almost never use it, but when I do it’s for two primary reasons. One, my Arch Linux installation is messed up and I’m in a hurry to get something done (usually related to my stupid webcam). And two, I like to experience Linux distributions that are setup to be visually attractive (unlike Arch Linux), to get ideas of what I can do to beautify my Arch Linux setup.
I reinstalled FreeBSD 9.1 x86_64. It’s funny, no matter how many times I try, I just don’t seem to get FreeBSD. Well, I decided to give it yet another shot. Video, audio, and networking are all working great. I’ll try compiling and installing some more packages tonight.
I have one partition split into to UFS slices, one for the operating system and one for my home directory.
And thus ends my experience updating the all of my operating systems!
]]>My goal here is to provide two things:
As much as possible, I will try to have inline citations in the form of hyperlinks. However, this document is the culmination of more Google searches than you can shake a stick at, so that won’t always be possible. Further, many examples I give are self-written and tested. This will be a multi-part document, since I have no intention of writing everything I’ve learned about JavaScript classes in one sitting. Before I begin in earnest, remember that Google is thy friend. Enterprise jQuery is also thy friend. I learned a ton reading their posts and anyone doing serious JS coding would do well to follow suit. Now, on to the show!
An Intro to the Prototype Model
In the traditional class-based model, the programmer writes a class definition that is separated from the actual data it will later be filled with. The class definition is not concerned with the specific values it will be used for, only with the things the class will do. Functions and data types are often tied to the class, which will later be filled with specific sets of data to operate upon. In order to actually use the class, instances have to be created. The core difference between these two models is in this distinction. In the prototype-based model, everything is an object and can already be used. A ‘class’ is created by defining an object with a set of properties. This is a real object and can be operated upon immediately. In order to have multiple instances of an object, each storing separate data (much like class instances), the object is cloned.
| Class-Based Programming | Prototype-Based Programming |
|---|---|
|
|
Table 1. ‘Class’ Creation Workflow
The prototype model is extremely flexible and, as I will show later, it can be used to create a variety of different class types including your bog-standard containers and more rarified ones like singletons. In fact, we can use its flexibility to hide the fact that we are actually cloning object instances and make it appear as though we are truly creating new instances a la C++! But I’m getting ahead of myself! Before diving into classes, some more basic concepts are extremely important to one’s understanding of why things are written the way they are in JavaScript. I will begin with the difference between using literal notation and the new command.
Literally Declaring
While using the ‘new’ command may appear to be the more sane and less expensive way to create arrays and objects, that is actually not the case! As those benchmarks show, the array literal notation is roughly twice as fast (in my browser, at least) as using the new command. Meanwhile, the object literal is an astonishing five times as fast as the new command. Moral of the story: don’t use the new command.
What’s the point of that aside? Well, to have a JavaScript class you need an object. Remember: everything is an object. There are no header files defining class structure. The moment you instantiate an object, it can be anything you want. So, let’s create an object!
var car = {};
Well, that was anti-climactic. Of course, we’ll want our object to have some properties, won’t we? So let’s define some of those:
var car = {
year: 1990,
manufacturer: "Ford",
miles: 300000
};
“Wait!” you may say, “that’s not a class!” That is correct. It isn’t a class. It’s an object. Understanding how these are structured is important for being able to write your own. This object that we just created has three properties: year, manufacturer and miles. They can be accessed the same was as public member variables in C++:
console.log(car.year); // output: 1990
What happens if we were to make a typo?
console.log(car.yera); // output: undefined
Makes sense, right? car.yera is undefined, so when you try to print it in the log, it spits out undefined. undefined is a special value in JS. It is comparable to Java’s null. There is no ‘special’ value in C++ for null or undefined, but 0 is commonly used (usually with #define NULL 0 if your libraries haven’t done that already).
Examine this code and guess at what should happen, then run it in your friendly neighborhood console and check the results:
var car = {
year: 1990,
manufacturer: "Ford",
miles: 300000
};
car.yera = 1982;
console.log(car);
Most C++ programmers like myself expect an error, but that doesn’t occur! Instead, the property ‘yera’ is added to the ‘car’ object. Here is something extremely important to grasp early on: each JavaScript Object is nothing more than an associative array mapping strings to values. In fact, you can do the following:
var car = {
year: 1990,
manufacturer: "Ford",
miles: 300000
};
car["yera"] = 1982;
console.log(car);
So now you know how to construct both types of arrays (numeric-associative and string-associative) in JavaScript. How can one use that to create a class? Well, here is one naive way:
var Car = function(year, manufacturer, miles) {
return {"year": year, "manufacturer": manufacturer, "miles": miles};
};
var myClunker = Car(1990, "Ford", 300000);
console.log(myClunker);
We create a function, assign it the name Car (note: function Car(year, manufacturer, miles) is equivalent in this case), and then create an object using the function. In this case, the function ‘Car’ is our constructor. What if we want a function in our object? As you can see above, one can assign a function to a variable. This is akin to using function pointers in C/C++. In fact, you can store functions as properties of objects. I’ll leave figuring out how to do that up to your imagination.
There is one last thing to understand before I display the code used to make a class (or namespace, as it happens, but I’m getting ahead of myself). JavaScript is a scripting language, exactly as its name applies. If you put any of the above code into a JS file and reference it from HTML, it will be executed. If you put that last snippet in, it will output the Object myClunker. myClunker and Car will both be accessible from the console and other JS files.
Putting It Together
The naive way I showed you a moment ago, while working, isn’t very good. For one thing: you can’t have private member variables. For another, it’s not very clean. Never fear! There is a solution. I proudly present to you: Car!
var Car = (function() {
function Car(year, manufacturer, miles) {
this.year = year;
this.manufacturer = manufacturer;
this.miles = miles;
}
return Car;
})();
var myClunker = new Car(1990, "Ford", 300000);
console.log(myClunker); // output: Car {year: 1990, manufacturer: "Ford", miles: 300000}
This ought to look more familiar. Maybe. We have a function Car which is the constructor for our class Car. What is this (function() {….})(); doohickey doing, though? That is a self-executing anonymous function.
That’s all for today. Tomorrow, I will get into the meat of fleshing the Car prototype out.
]]>Gittip is a platform to use generosity to crowdfund kickass content creators, from musicians to artists authors (like me) to developers like these. The communities feature allows us to see what other Archers are doing for their distro.
I want to strongly encourage our developers, Trusted Users, and even the retirees (including me) to join the community so we can start funding you. As Arch Schwag maintainer, I — perhaps more than anyone — know just how generous this community is with both their time and their money. Let’s start sharing our money with those users who are willing to share their time with us.
Arch devs are a pretty humble bunch, for the most part who might not think they deserve funding. So please encourage them to set up gittip profiles so that we can tip them. Over time, I hope some of them will be earning enough from gittip to take some time from their day jobs and help Arch improve at an even faster, bleeding edge pace.
Finally, I’d like to note that Chad Whitacre, founder of gittip has mentioned a plan to support funds, a way to tip entire organizations or communities such that the funds are distributed by the crowd. When this is implemented, I intend to donate Arch Linux Schwag income to this vessel, rather than through the Arch Linux donations page, as I have done for years. The Arch Schwag funds are not actually terribly useful to the project, aside from offsetting server costs and the like. I believe that tipping our developers directly will be much more beneficial to the project. Indeed, I can imagine the Arch Linux team funneling some of the donation money back into the gittip community in the future.
]]>So, let me tell you about MMORPGs. They scare me. I’ve never played them, but I’ve watched, and lost, friends that do. MMORPGs look boring to me. They look like mindless grinding for the simple purpose of making a number increase that resides on a computer somewhere that could get erased at any moment. How ridiculous.
And then one day I suddenly realized: I do play an MMORPG. It’s called the Arch Linux forums. I log in every day for at least an hour. I play with other people from around the world. I monitor my stats as they increase. I don’t think I’ve fought any battles, unless you count Vim vs EMACS. Anyway, it was a harsh realization.
I’m more active on the Arch Linux forums than anywhere else on the Internet by far. It’s my hobby. It’s enjoyable. It doesn’t feel like a chore. Sometimes I ponder what it would be like to become a moderator, but I quickly remember how much I enjoy not having any responsibilities there. Plus, I’d probably abuse my powers. “You have violated forum etiquette by recommending EMACS. Closed. Binned. For deletion.”
The Arch Linux forums and wiki are kind of a big deal on the Internet. As some of the best technical resources for Linux, users from all types of distributions find their way to them for help. And it’s so easy to contribute to. Anyone can create an account and start answering quesions and posting information.
I think it’s neat the way Arch Linux doen’t do any “advertising”. The developers have no desire to promote Arch Linux. Instead, they make the best operating system they can, and people interested in its features end up finding it (like I did). Arch Linux is one of the most popular Linux distributions, all based on its technical merit and community.
It’s been over three and a half years since I started using Arch Linux. I have no reason or desire to switch to anything else. Except maybe to get rid of systemd.
]]>Blö.
]]>Jag funderade länge och visste att min syster var lite sisådär intresserad av sin iPhone och skulle kunna tänka sig att sälja den. Jag blev då ganska intresserad, faktiskt. Främst för båda operativsystemen innehåller så mycket proprietär kod vilket skulle göra att det känns lite strunt samma vilket system man använde. När vi väl skulle komma till skott så visade det sig att hennes telefon var operatörslåst till Felia (företag sysslar tydligen med sådant 2013). Nu i efterhand är jag dock tacksam för det. Hon har i detta nu min telefon på lån, men kommer med största sannolikhet att köpa den.
Jag beslöt mig för att gå in på blocket.se för att se om det fanns någon billig N900 att köpa, och hittade en för 600 kronor. Till det priset var jag tvungen att köpa en. Nu i efterhand ångrar jag inte mitt köp. Det känns helt enkelt bättre, och det fysiska tangentbordet har jag verkligen saknat. Den här telefonen kommer jag nu att ha tills något nytt kommer ut på marknaden. Tizen, Sailfish OS, Firefox OS och Ubuntu är bara några som verkar intressanta och värda att hålla utkik efter.
Det finns mängder med gigantiska communitys för Android, vilket är en av dess styrkor. Till Maemo (operativsystemet N900 använder sig utav) finns det ett också. Det är inte speciellt stort, men det finns engagerade utvecklare som fortfarande håller igång, även om telefonen är från 2009. Vad dessa gör är bland annat att fixa buggar, och att försöka att ersätta den någorlunda lilla mängd proprietär kod som finns, med öppen källkod. Kolla bara in CSSU. Jag önskar jag kunde lära mig att programmera, då skulle jag försöka engagera mig i det också, men jag får nöja mig med att bruka deras verk.
Så. Vad kommer jag att sakna hos Android då? Självfallet, dess utbud av appar. Främst de appar jag har köpt, men också Swedbanks app, och appen för kollektivtrafiken i det län jag bor i (skulle jag någon gång få för mig att börja programmera skulle jag försöka göra en sådan till Maemo).
Tack och hej.
]]>Öppna en ny flik -> skriv about:config (lova att du är försiktig!!) Sedan skriver du in följande:
general.autoScroll vilket du senare ändrar till true. Detta gör att du kan trycka på scrollen (eller middle click) för att scrolla snabbare.
browser.backspace_action ändrar du till 0. Vilket gör det möjligt att gå bakåt med bakåtknappen.
The price for a single Arch Linux Sticker has dropped from $1.90 to $1.35. The savings are even greater if you purchase in bulk; you can now order 20 stickers for 80 cents a piece!
Head over to schwag.archlinux.ca to order your stickers and other Arch Linux goodies. If you’re interested in more generic Arch Linux branded items, check out our Zazzle shop.
]]>I alla fall, vad jag har gjort är att skapa en egen mapp i .themes (döp den till vad du vill), sedan lägger du in de teman du vill ha (gtk2 och gtk3). Sedan går du in i inställningar och väljer du det namn du skrev när du skapade mappen. Då borde du ha de teman du valde. I mitt fall valde jag Candido-candy och Zukiwi som gtk3-tema. Helt perfekt, faktiskt. Nu slipper du installera applikationer från AUR som kompilerats med gtk2, enbart för att du valt ett tema som ej har något gtk3-tema. Smidigt, och fint!
Här kan du se det in action.
]]>cp /etc/xdg/xfce4/xfconf/xfce-perchannel-xml/xfce4-session.xml ~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-session.xml
vim ~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-session.xml
Leta upp xfwm4 och ersätt med gala. Spara och logga ut.
Här är en bild som kan ge ett hum om hur det kan se ut när det är färdigt.
]]>
Another indicator of forward momentum is that women this year were able to behave, to use a sexist term, “like women,” without fear of reprisal. That is to say, I saw makeup, heels, and skirts, and they did not seem out of place. This is not to suggest that women should or must dress up to attend conferences; the traditional vendorware is equally acceptable for all genders. However, it is progress that more women felt they had a choice in the matter and did not feel an obligation hide their physical differences. I think the fact that there was more variety among the male dress styles is also a sign of success.
The worst charges coming out of Pycon 2013 were the use of inappropriate jokes. To the best of my knowledge, there were no reports of women being harassed, assaulted, or groped during the conference. I’m not aware that this has been an issue at past Pycons either, but I think it’s a sign that the Python community is better behaved in this regard than some of her sister tech conferences.
So all in all, while it wasn’t completely successful, Pycon 2013 was a terrific step on the road to eliminating sexism and creating gender equality. Let’s make next year an equal sized step. Here are a few topics I think we, as a community, can work on to engender further progress.
I’m going to start with a couple links. Ruth Burr wrote a terrific essay titled Things You Think Aren’t Sexist, But Really Are a couple weeks ago. In summary: Men, you are instructed to go to conferences to network and interact, not to date or hook up.
Yes, you might meet the love of your life at Pycon, but don’t expect, intend, or plan for that to happen (at PyCon or anywhere). Behave professionally, and consider each woman you meet for her knowledge and intelligence, not her figure or her marital status, just as you would when interacting with a male.
Ned Batchelder, with his amazing talent for understanding and explaining problems wrote another great article on the root issues. Summarized, he says friction is inevitable, and that education is better than shunning when people make mistakes.
I started planning this article while attending Pycon this year. I had to scrap those plans after the so-memed “donglegate” fiasco. I don’t have anything to add to that discussion, but as Ned illustrated, there were many many instances of similarly inappropriate comments at Pycon. I myself made such a joke, most of my friends did so, I overheard a conference organizer say something inappropriate. This is not sexism per se, but sexual and other potentially offensive comments need to be reduced. Comments laced with sexual innuendo do not belong in a professional or a family setting, and Pycon is intended to be both.
Let’s start with interation between the genders. In her article, Ruth Burr mentioned that women can feel awkward when they interact with men because the men assume they are flirting rather than interested in the topic at hand. Many men see cleavage and assume the speaker can’t possibly know as much as them about whatever topic that is. Some girls avoid interacting with men because of this awkward sensation, and if they do, the interactions are tainted.
I had a related problem. While I comfortably talked to men of varying skill levels at Pycon, I felt uncomfortable addressing women because I was afraid of sending some vibe that I was being flirtatious. So I tended to ignore the female attendees. This is unfortunate for everyone who missed out on that potential conversation. Pycon 2014 needs to increase the interaction between the genders, not just the attendance ratios. Ladies, talk to the shy guys, they need to be taught that you aren’t that intimidating. Guys, talk to the women, they need to learn that we are interested in what they have to say about tech, and not their figures. As it stands, only the sexist guys are interacting with the women, and it makes us all look bad.
The gender ratio really fell during the developer sprints. I don’t think there were any female sprint leaders presenting projects to hack on. Worse, I’d estimate between one and two percent of the sprint attendees were women. This is a huge area for improvement. To the various diversity groups out there, please encourage your members to stay an extra day or two and attend the Pycon dev sprints. Get them involved with Open Hatch if they are unsure how to contribute to open source projects. Sprint leaders, make sure female attendees are welcome, especially if they are new coders (indeed, make all new coders welcome).
I noticed a lot of Impostor syndrome among the female attendees and speakers. Programming really is easy. The fact that you enjoy it and find it quite simple is not a sign that you don’t know the “hard stuff” and therefore you’re not a “real programmer.” Quite the reverse, in fact. It’s not necessary to apologize for your lack of knowledge if you’ve been invited to do a talk or are about to join an open source project for the first time. Find ways to build your confidence (contributing to open source and getting feedback is a great start), and start believing in your skills. Even if you don’t believe it yourself, try to project confidence in your coding abilities; it will send a much more effective signal that women are capable and here to stay. Don’t worry if you over-present yourself; faking your way through it is a great way to find out that you’re actually better than you thought!
I’d like to close with an admonishment to those people who open their articles on sexism with a discussion of their gender. These usually take one of two forms: the disclaimer and the shocker. The disclaimer is most often used by men and sounds like, “I am a privileged white male so I don’t understand what it’s like for women, but I still think I have something valid to say on this topic”. The shocker is used by both genders and sounds like, “I am a man/woman, so you’re going to be amazed that my opinion on this topic is different from other members of my gender.” Yes, it is useful to state your bias and frame of reference. However, be cautious that your purpose in doing so is to remove distortion from the lens you are applying to the discussion, not to add to it.
And now, feel free to analyze my bias in this article. I am a privileged white male from a blue-collar family. I’ve had many amazing opportunities in the tech industry. I have very little experience as the target of discrimination, outside my mental illness. My interest in feminist issues comes from my sister’s master’s degree on the subject; I proofread most of her undergraduate and graduate level essays, and gained a relatively deep understanding of the topic. I acknowledge that I am a racist, sexist jerk by culture and conditioning. Sometimes I forget to compensate for that. I find it exceptionally easy to overlook the patriarchy when it’s doing me favors, and I will never be as keenly aware of its negative impact as someone who is directly experiencing it every day.
]]>Instead, he presented a highly technical and very exciting addition to the Python language. Alfredo told me this started when he took a month off between stepping down at Google and starting at DropBox. Now, when normal people take a month off, they relax or travel or visit friends and family. Not our BDFL. He writes a callback-free asynchronous event loop API and reference implementation that is expected to massively alleviate Python’s oft-maligned lack of a consistent, unhackish concurrency solution.
Let’s have more of that. What if Mr. Van Rossum could hack on Python full time? Would we see quantum progress in Python every month?
Anyone who knows about the Gittip project likely thinks they can guess where this is going. We, the people, can each tip our BDFL a few cents or dollars per week so he can focus on whatever he deems worthy. It’s safe to assume that a man who spends his vacation time drafting a new Python library would choose to work on Python full time if we funded him.
This plan is great, and I actually think that Guido could easily earn enough to quit his day job if he endorsed Gittip and invited individuals to tip him. But I’d like to discuss a different plan: Not individuals, but companies should tip Guido the maximum gittip amount as a sort of “partial salary”. At $1248 per year, most companies wouldn’t even notice this expense, and they would get a better programming language and standard library in return. The rate of accelerated development would be even higher if each of these companies chose to invest an entire salary, split between a hundred Python core and library developers. If a hundred companies chose to do this, those hundred people could work on Python full time. The language and library would improve so vastly and so rapidly that the return on investment for each of those companies would be far greater than if they had paid that same salary to a single developer working on their in-house product, full time.
It might take some convincing to justify such a strategy to these corporations. Companies tend to like to know what is happening to their money, and simply throwing a hefty developer salary at Gittip would be hard to justify. Obviously “goodwill” could support some of it, in the same way that so many companies sponsored Pycon in exchange for exposure.
Cutthroat CEOs should perhaps consider not just the value that having Guido working exclusively on Python is, but also the cost of having him work for the competition. I’m sure Box.com CEO Aaron Levie was a little nervous when he found out that the first and greatest Python programmer of all time had recently hired on at a major competitor. Perhaps Box.com can’t afford to steal Guido from Dropbox, but if all the companies currently involved in cloud storage were to tip Guido $24 per week on Gittip, this incredible programmer could be working on an open source product that directly and indirectly benefits their company rather than improving the competing product on a full-time basis.
Most of the arguments that Gittip will fail are based on the premise that not enough money can be injected into the platform to sustain full time development by open source programmers. However, if an open and caring relationship can be built such that the corporate world is also funding the system, I think it can become extremely successful. Everyone will benefit: Open source projects will improve at a rapid pace. Exceptional developers will get to pursue their passions. End users will get better products. The overall level of happiness in the world will be higher.
I would like to see a world where brilliant young software engineers are not risking their mental health (and consequently, their lives) on startup ideas in the hopes of being bought out for a few billion dollars. I would like to see a world where those engineers are not working for large corporations that have neither their employees nor their end users (but rather, their stockholders and advertisers) interests at heart. I would like to see a world where those developers can choose to invest their passion in open source products that will change the world.
]]>Jag verkar ha svårt att kunna lägga upp bilder just nu, så därför kan jag inte posta en skärmbild på hur det ser ut för tillfället. Vad jag dock kan göra är att förmedla det tema och de ikoner som används för tillfället.
GTK thema: Mint-themes
Ikoner: Mint-x-icons
Tack för mig.
]]>
Dessa tillägg har jag till GNOME, de är alla väldigt bra och fyller sin funktion:
The three things that I have still been using Google for were:
I still use Google maps on occasion, though my main navigation equipment is an offline Garmin GPS device that — to the best of my knowledge — is not notifying anyone of my location at any time. I largely addressed the other two issues this past week.
I recently received my Cubieboard in the mail. It’s basically a specced up Raspberry PI. I installed Arch Linux by following the instructions at this thread.
I then set up Own Cloud by following the instructions at the Arch wiki. Once it was set up, I realized that I personally don’t have much use for calendar sync or file sharing, but that the contact backup was crucial. I didn’t want a full LAMP stack running on my little ARM processor, so I uninstalled Own Cloud and set up Radicale instead. Now my phone’s contacts are backed up and I no longer need my Google account to support that feature.
Then I was notified that AOKP, my current Android ROM of choice, had released an update. I thought “Hm, I wonder if I can get away with not installing the Google Apps package at all.”
I couldn’t. But I tried. The main issue is that there are two paid apps in my Google Play account (SwiftKey and SwipePad MoreSpace) that I do not want to live without, and do not want to purchase again from another vendor. In the case of SwipePad, I couldn’t even find another vendor. I toyed with backing up and restoring the .apk’s, but I got certificate and signing errors. I’ve read that these can be circumnavigated with Titanium Backup, but I haven’t gotten around to trying it yet.
So I installed Google apps and reluctantly activated my Google Account to install these two paid apps. Then I disabled my Google Account.
I then installed Aptoide to replace Google Play. It had recent versions of all the free apps I use on a regular basis. It looks like it will be able to supply my app needs into the future.
I have logged into my Gmail account and deleted my pre-existing contact list. This means that even if I do have to enable Google Play in the future, I will no longer be spammed with “Your friends like this app” messages. It also means Google will not be able to track my future relationships unless they are with people who use Google services.
Now if only Ghostery and Firefox would get Ghostery working on Android, I’d actually feel safe using my device!
]]>
]]>
Manjaro XFCE, by manjaro.org
A weekend off in the middle of winter – just perfect to test a new Linux distro. I decided on Manjaro, the new star among Arch- based Linux distros (currently ranked 15 on Distrowatch) which seems to be on the best way to become something like “Mint for Arch”.
So what does Manjaro do on top of Arch ?
The most important feature is of course the pre- configured desktop environment. Manjaro uses XFCE by default, and there are official Openbox and Cinnamon versions and a headless “Net” variant. KDE, Mate and LXDE are offered as “community editions” with a different release schedule. The 1GB XFCE image (32 Bit) has all you need for daily work, including gParted, the VLC mediaplayer, Abiword, Gnumeric and Gimp for Office purposes, Chromium, Pidgin and Xchat for internet access, and even Steam for gaming.
The installer is text based and closely resembles the old Arch installer (those were the days …). While installing the system is not complicated, there’s certainly room for improvement if you compare the process to established end user distributions like Ubuntu, SUSE or even Fedora. The graphical package / upgrade manager Pamac handles pacman packages from a special, tested Manjaro repository which is updated regularly (usually once a week) in a rolling release model, yaourt is included for easy AUR access.
I’m not sure about the current state of things in Arch, but Majaro runs very smooth. All hardware was recognized successfully. The only changes I did are more a matter of preference, I removed pulseaudio (using gnome-alsamixer as mixer) and configured Ubuntu- style 2 finger right mouse tap by adding ‘synclient TapButton2=3 TapButton3=2′ as new startup command in the ‘Session and Startup’ settings.
Manjaro lives up to the expectation of an easy, polished and stable Linux distribution. The desktop layout with the XFCE panel on top and Plank dock at the bottom looks very clean and modern, in fact it looks like a combination of Elementary OS and Mint. The Pamac graphical package manager is the first application of that type on an Arch- based system that is actually usable. The only thing missing to take on the Mints, Ubuntus and SUSEs of the world is a graphical Installer, but there’s already one in the works.
]]>->com->canonical->indicator->datetime. Sedan väljer du de alternativ du är intresserad av.
]]>