Kamil is the creator of TickCounter, a simple online time counter. It allows you to create countdown and countup timers as well as measure time with stopwatches and egg timers.
TickCounter is hosted by PythonAnywhere, a Python-focused PaaS and browser-based programming environment.
Read more…Well, from our point of view, one of the most important things in this release was probably the akismet integration which we hope will prevent forums spam, and thus save us a tedious admin process of deleting spammy posts. So you’ll have to go somewhere else for your updates on which are the food supplements for muscle growth.
But we do also care about users of the site other than ourselves, so we’re equally pleased to announce a nice little features on the Consoles page, “Custom” launchers. You can use them to create your own console types, little shortcuts for running your favourite scripts. Congrats to our newest employee Conrad for coming up with this idea, and pushing tirelessly to get it out.
We’ve added the ability for you to nominate a “teacher”, as part of our education beta, so you can now use PythonAnywhere’s education features for ad-hoc programming workshops or training sessions, without needing to tell us in advance who your students will be. Just get attendees to sign up, fill in the teacher field, and you’re good to go.
Other than that, we’ve made some minor tweaks to the process dashboard – you can now see how much CPU each process has used, so you can identify those CPU-quota-nommming rogue tasks, and we’ve added a little warning on the web tab to detect mis-matches between your virtualenv python version and the web application’s.
Hope you find this all useful! As ever, we’re always interested in feedback and suggestions. Mesozoic mammals, yo.
Hi guys,
Today, I want to change gears a little bit and talk about our TDD development process, which has always been very dear to our hearts. Just as a disclaimer, this is going to be a very general overview and if you are an experienced TDD developer, you may not get a lot out of it. However, continuing along the mentorship/educational theme, I hope this will be useful for the people out there who are just starting out, and are trying to figure out what is a good style/process for developing.
Read more…Hi guys,
Here’s a long overdue post about my work environment.
Read more…Welcome to PythonAnywhere’s latest newsletter. Latest not only because it’s the most recent, but also because it’s the most overdue!
Hi there fellow nerds! Another edition of our incredibly-rare-and-infrequent-newsletter (currently coming out about once a year).
Read more…Hi guys,
With today’s deploy, we added some console sharing and file system features to make helping other people easier, whether it’s in a group setting, or a more in-depth one-on-one session.
It’s been great to see more and more initiatives to teach Python, over the last few years, but it’s never as easy as it should be. Personally, we have definitely experienced the struggle of our friends who are new to programming, from general commandline stuff and installing modules, to understanding different error messages and trace backs etc. We want to see if there’s more we can to do help make the mentoring process as easy and painless as possible.
tl;dr: go mentor someone today and tell us how to make the sharing features even better for you!
We also continued on our epic quest towards zero downtime by stupidifying the file server. Previously, our file server shared the same code base as our web/console servers, and used the django code to do tasks such as updating user storage quotas (eg: after an account upgrade). It was a good idea at the time because it meant that we could handle a quota update request, grab what a user’s storage quota changed to, and then apply the new quota- all very easily from within django.
However, this violates the concept of keeping things modular and meant that we had an extra dependency to manage properly. Whenever we updated the source code and wanted to push it out to production, this meant that we needed to do it to the file server as well. This then meant that we needed to make sure nobody was writing to the file server during that time and that all the changes were flushed to disk. This is one reason why we needed downtime when deploying (to ensure data consistency etc).
Anyway, now all the fileserver has on it is a minimal flask microservice independent of our main django code, so the hope is that we can cut out this particular source of downtime. Yay!
Last Tuesday, we changed the filesystem we use to store our users’ files over from XFS to ext4fs. This required a much longer maintenance outage than normal – 2 hours instead of our normal 20-30 minutes.
This post explains why we made the change, and how we did it.
Read more…Morning all!
So the reason for our extra-long maintenance window this morning was primarily a migration from XFS to ext4 as our filesystem for user storage. We’ll write more about the whys and wherefores of this later, but the short version is that the main reason for using XFS, project quotas, were no longer needed, and a bug in the version of XFS support by Ubuntu LTS left us vulnerable to long periods of downtime after unplanned reboots, while XFS did some unnecessary quotachecks. The switch to ext4 removes that risk, and has simplified some of our code too, bonus!
In other news, we’ve managed to squeeze in a few more user-visible improvements :)
We’ve decided to tweak the pricing and accounts pages so that all plans are customisable. As a bonus side-effect, we’ve slightly improved all the existing paid plans, so our beloved customers are going to get some free stuff:
bottlenose, python-amazon-simple-product-api, py-bcrypt, Flask-Bcrypt, flask-restful, markdown (for Python 3), wheezy.template, pydub, and simpy (for Python 3) are now part of our standard batteries included
We’ve re-written our server build scripts to use wheels, and to build them for each package we install. We’ve made them available (at /usr/share/pip-wheels), and we’ve added them to the PythonAnywhere default pip config. So, if you’re installing things into a virtualenv, if it so happens we already have a wheel for the package you want, pip will find it and the install will complete much faster.
The “Save and Run” button at the top of the editor, much beloved of teachers and beginners (and highly relevant for our education beta) now defaults to Python 3. It’s 2015, this is the future after all. We didn’t want to break things for existing users, so they will still have 2 as the default, but we can change that for you if you want. Just drop us a line to support@pythonanywhere.com
Other than that, we’ve added a few minor security and performance tweaks.
Onwards and upwards!
Hi guys,
I’m Conrad- a new member of the PythonAnywhere team. As a rather junior and beginner programmer, I would like to share with you my story of how I set up my work environment- my rationale for choosing and customizing my text editor, my shell, my windows manager etc, and what I learned along the way.
Read more…