Срок службы носителей данных

Web 3.0

Веб 3.0: мобильная эра Интернета

Python приложение для Android

http://kivy.org/

http://pygame.renpy.org/

http://habrahabr.ru/post/149898/

Coffee Script

Tutorials

http://www.ibm.com/developerworks/ru/library/wa-coffee1/
http://www.ibm.com/developerworks/ru/library/wa-coffee2/
http://www.ibm.com/developerworks/ru/library/wa-coffee3/

Converter
convert JavaScript code to CoffeeScript

Как проще всего в Ubuntu обновить дополнения к VirtualBox

http://www.kv.by/content/kak-proshche-vsego-v-ubuntu-obnovit-dopolneniya-k-virtualbox

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install dkms

Далее открываем страницу с последними готовыми продуктами для виртуальной машины VM VirtualBox (на дату написания статьи – версия 4.1.18).

Скачиваем образ дополнений: VBoxGuestAdditions_4.1.18.iso. По умолчанию он скачается в папку «Загрузки». Далее смотрим, где находится старый образ дополнений, и копируем в ту же папку новый образ. Чтобы найти, где находится старый образ, запускаем VirtualBox, но не стартуем виртуальную ОС, а идём «Машина-Свойства-Носители», кликаем по изображению привода оптических дисков, подписанному, как VboxGuestAdditions, и смотрим путь, прописанный в атрибуте «Расположение». После копирования не пытайтесь сразу подменить старый образ новым с помощью настройки привода оптических дисков! Дело в том, что ваша виртуальная ОС в своих конфигурационных файлах помнит путь к прежнему образу и будет устанавливать дополнения именно из него. Сначала запустите виртуальную ОС. 

Снова идите «Машина-Свойства-Носители-VboxGuestAdditions-Атрибуты-Привод-Настроить привод оптических дисков-Выбрать образ оптического диска». Далее в открывшемся файловом диалоге найдите образ новых дополнений и дважды кликните по нему. Убедитесь, что в свойствах носителей появился путь к новому образу. 

Вот только теперь можно устанавливать новые дополнения к гостевой машине, т.е., как обычно: «Устройства-Установить дополнения гостевой ОС». Ждём, пока устанавливаются новые дополнения, затем перезагружаем виртуальную ОС. В системном трее виртуальной ОС щёлкаем по иконке дополнений (кубик такой) и убеждаемся, что после перезагрузки были автоматически установлены новые дополнения. 

При необходимости описанным методом можно откатиться к прежним дополнениям. Если, конечно, вы их не удалили. :)

django dash 2012 results

http://djangodash.com/judging/c3/results/

Meteor

Meteor is an open-source platform for building top-quality web apps in afraction of the time, whether you're an expert developer or just getting started.

pgfouine

http://pgfouine.projects.postgresql.org/reports.html -  is a PostgreSQL log analyzer used to generate detailed reports from a PostgreSQL log file. pgFouine can help you to determine which queries you should optimize to speed up your PostgreSQL based application.

Porting Django to Python 3

https://docs.djangoproject.com/en/dev/topics/python3/

ZeroMQ

http://blog.pythonisito.com/2012/08/distributed-systems-with-zeromq.html

One of the first things to understand about ZeroMQ is that it's not a message broker like you might assume from its name. ZeroMQ is a library that supports certain network communication patterns using sockets. The "MQ" part comes in because ZeroMQ uses queues internally to buffer messages so that you don't block your application when sending data.

http://blog.pythonisito.com/2012/08/zeromq-flow-control-and-other-options.html

DNS in Ubuntu 12.04

http://www.stgraber.org/2012/02/24/dns-in-ubuntu-12-04/

Any change manually done to /etc/resolv.conf will be lost

Resolvconf has a /etc/resolvconf/resolv.conf.d/ directory that can contain “base”, “head”, “original” and “tail” files. All in resolv.conf format.

• base: Used when no other data can be found 
• head: Used for the header of resolv.conf, can be used to ensure a DNS server is always the first one in the list 
• original: Just a backup of your resolv.conf at the time of resolvconf installation 
• tail: Any entry in tail is appended at the end of the resulting resolv.conf. In some cases, upgrading from a previous Ubuntu release, will make tail a symlink to original (when we think you manually modified resolv.conf in the past) 

“nm-tool” can be used to get information about your existing connections in Network Manager. It’s roughly the same data you’d get in the GUI “connection information”.

Alternatively, you can also read dnsmasq’s configuration from /run/nm-dns-dnsmasq.conf

sudo restart network-manager

Python socket.io server implementation on top of Tornado framework

https://github.com/mrjoes/tornadio2

Python Serial Port Extension

http://pyserial.sourceforge.net/

Распознание текста с картинки

http://code.google.com/p/pytesser/
http://code.google.com/p/python-tesseract/

How to test Selenium CSS and XPath expretions in Chrome

You can simply test them in console:

// XPath syntax:
$x("EXPRESSION_HERE")
 
//CSS syntax:
$$("EXPRESSION_HERE")

Model permissions

https://github.com/sunlightlabs/django-gatekeeper/
https://bitbucket.org/rajeesh/django-monitor/

geo

from geopy import geocoders, distance
g = geocoders.Google(domain='maps.google.ru')

place, location = g.geocode(u"Беларусь, Минская область, Прилесье".encode('utf-8'))
place2, location2 = g.geocode(u"Беларусь, Минск, Рокосовского".encode('utf-8'))

distance.distance(location, location2)
Distance(11.4758281895)

django-chickpea

Decimal, Fraction

http://asvetlov.blogspot.com/2012/08/numerics.html

Decimal
Наиболее практичный способ — создание своего контекста и применение его в with statement:

>>> from decimal import Context, localcontext
>>> with localcontext(Context(4)):
... print(repr(Decimal("1.10") / 3))
Decimal('0.3667')

Округление:

>>> Decimal('1.12').quantize(Decimal('0.1'))
Decimal('1.1')
>>> Decimal('1.16').quantize(Decimal('0.1'))
Decimal('1.2')

Внимание! Округлять можно только до той максимальной точности, которая позволена текущим контекстом. Сейчас у нас глобальный контекст имеет точность 2.

>>> getcontext().prec = 2
>>> Decimal('1.10').quantize(Decimal('0.000001'))
Traceback (most recent call last):
...
decimal.InvalidOperation: quantize result has too many digits for current context

Fraction

>>> from fractions import Fraction
>>> Fraction(25, 8) + Fraction(25, 8) == Fraction(50, 8)
True

Why escape-on-input is a bad idea

http://lukeplant.me.uk/blog/posts/why-escape-on-input-is-a-bad-idea/

Filter on input, escape on output

How to log an exception instance

http://blog.tplus1.com/index.php/2012/08/05/python-log-uncaught-exceptions-with-sys-excepthook/

If you do any of these, you probably won’t like what you get:

logging.error(ex)
logging.error(str(ex))

In both cases, you are just turning the exception to a string. You won’t see the traceback and you won’t see the exception type.
Instead of those, make sure you do one of these:

logging.exception(ex) # this is exactly what logging.exception does inside
logging.error(ex, exc_info=1) # sets a higher log level than error 
logging.critical(ex, exc_info=1)

For the last two, without that exc_info=1 parameter, you won’t see the traceback in your logs. You’ll just see the message from the exception.

Tox to test across Python versions

Tox as is a generic virtualenv management and test command line tool you can use for:

• checking your package installs correctly with different Python versions and interpreters
• running your tests in each of the environments, configuring your test tool of choice
• acting as a frontend to Continuous Integration servers, greatly reducing boilerplate and merging CI and shell-based testing.

JavaScript frameworks

http://coding.smashingmagazine.com/2012/07/27/journey-through-the-javascript-mvc-jungle/

Is there a way to dynamically refresh the less command?

Shift+F

Learn Python The Hard Way - Zed A Shaw - 2010

Function Style
All the other rules I’ve taught you about how to make a function nice apply here, but add these things:

• For various reasons, programmers call functions that are part of classes methods. It’s mostly marketing but just be warned that every time you say “function” they’ll annoyingly correct you and say “method”. If they get too annoying, just ask them to demonstrate the mathematical basis that determines how a “method” is different from a “function” and they’ll shut up.
• When you work with classes much of your time is spent talking about making the class “do things”. Instead of naming your functions after what the function does, instead name it as if it’s a command you are giving to the class. Same as pop is saying “Hey list, pop this off.” It isn’t called  remove_from_end_of_list because even though that’s what it does, that’s not a command to a list.
• Keep your functions small and simple. For some reason when people start learning about classes they forget this.

Class Style

• Your class should use “camel case” like SuperGoldFactory rather than super_gold_factory.
• Try not to do too much in your __init__ functions. It makes them harder to use.
• Your other functions should use “underscore format” so write my_awesome_hair and not myawesomehair or MyAwesomeHair.
• Be consistent in how you organize your function arguments. If your class has to deal with users, dogs, and cats, keep that order throughout unless it really doesn’t make sense. If you have one function takes (dog, cat, user) and the other takes (user, cat, dog), it’ll be hard to use.
• Try not to use variables that come from the module or globals. They should be fairly self-contained.
• A foolish consistency is the hobgoblin of little minds. Consistency is good, but foolishly following some idiotic mantra because everyone else does is bad style. Think for yourself.
• Always, always have class Name(object) format or else you will be in big trouble.

Code Style

• Give your code vertical space so people can read it. You will find some very bad programmers who are able to write reasonable code, but who do not add any spaces. This is bad style in any language because the human eye and brain use space and vertical alignment to scan and separate visual elements. Not having space is the same as giving your code an awesome camouflage paint job.
• If you can’t read it out loud, it’s probably hard to read. If you are having a problem making something easy to use, try reading it out loud. Not only does this force you to slow down and really read it, but it also helps you find difficult passages and things to change for readability.
• Try to do what other people are doing in Python until you find your own style.
• Once you find your own style, do not be a jerk about it. Working with other people’s code is part of being a programmer, and other people have really bad taste. Trust me, you will probably have really bad taste too and not even realize it.
• If you find someone who writes code in a style you like, try writing something that mimics their style.

Good Comments

• There are programmers who will tell you that your code should be readable enough that you do not need comments. They’ll then tell you in their most official sounding voice that, “Ergo you should never write comments.” Those programmers are either consultants who get paid more if other people can’t use their code, or incompetents who tend to never work with other people. Ignore them and write comments.
• When you write comments, describe why you are doing what you are doing. The code already says how, but why you did things the way you did is more important.
• When you write doc comments for your functions, make the comments documentation for someone who will have to use your code. You do not have to go crazy, but a nice little sentence about what someone does with that function helps a lot.
• Finally, while comments are good, too many are bad, and you have to maintain them. Keep your comments relatively short and to the point, and if you change a function, review the comment to make sure it’s still correct.

http://learnpythonthehardway.org/

Expert Python Programming: Best practices for designing, coding, and distributing your Python software - Tarek Ziadé - 2008

context, contextlib http://www.doughellmann.com/PyMOTW/contextlib/index.html

Multiple Inheritance Best Practices

__mro__: If __mro__ is available, have a quick look at the code of the constructor of each class involved in the MRO. If super is used everywhere, it is super! You can use it. If not, try to be consistent.

__slots__ : An interesting feature that is almost never used by developers is slots. They allow you to set a static attribute list for a given class with the __slots__ attribute, and skip the creation of the __dict__ list in each instance of the class. They were intended to save memory space for classes with a very few attributes, since __dict__ is not created at every instance.

The latter can be avoided with the "-O" option of the interpreter. In that case, all assertions are removed from the code before the byte code is created, so that the checking is lost.

Anyhow, many DbC libraries exist in Python for people that are fond of it. You can have a look at Contracts for Python.

Another approach towards this is "fuzz testing", where random pieces of data are sent to the program to detect its weaknesses. When a new defect is found, the code can be fixed to take care of that, together with a new test.

The warnings module will warn the user on the first call and will ignore the next calls. Another nice feature about this module is that filters can be created to manage warnings that are impacting the application. For example, warnings can be automatically ignored or turned into exceptions to make the changes mandatory. See http://docs.python.org/lib/warning-filter.html http://docs.python.org/library/warnings.html#available-functions http://django-notes.blogspot.com/2012/05/deprecationwarning-django-14.html

The web location used to find the package is the same as that used by easy_install is http://pypi.python.org/simple, which is a web page not intended for humans that contains a list of package links that can be browsed automatically.

dia
autodia -l python -f manage.py
autodia -l python -d apps/integrations/salesforce/ -r

Munin is a great system-monitoring tool that you can use to get a snapshot of the system health.

Gprof2Dot can be used to turn profiler data into a dot graph. You can download this simple script from http://jrfonseca.googlecode.com/svn/trunk/gprof2dot/gprof2dot.py and use it on the stats as long as Graphviz  is installed in your box

KcacheGrind is also a great vizualization tool to display profile data.

The PyMetrics project from Reg Charney provides a nice script to calculate the cyclomatic complexity

The Twisted framework, which comes with a callback-based programming philosophy, has ready-to-use patterns for server programming. Last, eventlet is another interesting approach, probably simpler than Twisted.

The Art of Unix Programming

http://www.faqs.org/docs/artu/index.html

Code Simplicity - Max Kanat-Alexander - 2012

Fact: The difference between a bad programmer and a good programmer is understanding. That is, bad programmers don’t understand what they are doing, and good programmers do.

Rule: A “good programmer” should do everything in his power to make what he writes as simple as possible to other programmers.

Definition: A program is:

1. A sequence of instructions given to the computer
2. The actions taken by a computer as the result of being given instructions

Definition: Anything that involves the architecture of your software system or the technical decisions you make while creating the system falls under the category of “software design.”

Fact: Everybody who writes software is a designer.

Rule: Design is not a democracy. Decisions should be made by individuals.

Fact: There are laws of software design, they can be known, and you can know them. They are eternal, unchanging, and fundamentally true, and they work.

Law: The purpose of software is to help people.

Fact: The goals of software design are:

1. To allow us to write software that is as helpful as possible
2. To allow our software to continue to be as helpful as possible
3. To design systems that can be created and maintained as easily as possible by their programmers, so that they can be—and continue to be—as helpful as possible

Law: The Equation of Software Design:

This is the Primary Law of Software Design. Or, in English:

The desirability of a change is directly proportional to the value now plus the future value, and inversely proportional to the effort of implementation plus the effort of maintenance.

As time goes on, this equation reduces to:

Which demonstrates that it is more important to reduce the effort of maintenance than it is to reduce the effort of implementation.

Rule: The quality level of your design should be proportional to the length of future time in which your system will continue to help people.

Rule: There are some things about the future that you do not know.

Fact: The most common and disastrous error that programmers make is predicting something about the future when in fact they cannot know.

Rule: You are safest if you don’t attempt to predict the future at all, and instead make all your design decisions based on immediately known present-time information.

Law: The Law of Change: The longer your program exists, the more probable it is that any piece of it will have to change.

Fact: The three mistakes (called “the three flaws” in this book) that software designers are prone to making in coping with the Law of Change are:

1. Writing code that isn’t needed
2. Not making the code easy to change
3. Being too generic

Rule: Don’t write code until you actually need it, and remove any code that isn’t being used.

Rule: Code should be designed based on what you know now, not on what you think will happen in the future.

Fact: When your design actually makes things more complex instead of simplifying things, you’re overengineering.

Rule: Be only as generic as you know you need to be right now.

Rule: You can avoid the three flaws by doing incremental development and design.

Law: The Law of Defect Probability: The chance of introducing a defect into your program is proportional to the size of the changes you make to it.

Rule: The best design is the one that allows for the most change in the environment with the least change in the software.

Rule: Never “fix” anything unless it’s a problem, and you have evidence showing that the problem really exists.

Rule: In any particular system, any piece of information should, ideally, exist only once.

Law: The Law of Simplicity: The ease of maintenance of any piece of software is proportional to the simplicity of its individual pieces.

Fact: Simplicity is relative.

Rule: If you really want to succeed, it is best to be stupid, dumb simple.

Rule: Be consistent.

Rule: Readability of code depends primarily on how space is occupied by letters and symbols.

Rule: Names should be long enough to fully communicate what something is or does without being so long that they become hard to read.

Rule: Comments should explain why the code is doing something, not what it is doing.

Rule: Simplicity requires design.

Rule: You can create complexity by:

• Expanding the purpose of your software
• Adding programmers to the team
• Changing things that don’t need to be changed
• Being locked into bad technologies
• Misunderstanding
• Poor design or no design
• Reinventing the wheel
• Violating the purpose of your software

Rule: You can determine whether or not a technology is “bad” by looking at its survival potential, interoperability, and attention to quality.

Rule: Often, if something is getting very complex, that means there is an error in the design somewhere below the level where the complexity appears.

Rule: When presented with complexity, ask, “What problem are you trying to solve?”

Rule: Most difficult design problems can be solved by simply drawing or writing them out on paper.

Rule: To handle complexity in your system, redesign the individual pieces in small steps.

Fact: The key question behind all valid simplifications is, “How could this be easier to deal with or more understandable?”

Rule: If you run into an unfixable complexity outside of your program, put a wrapper around it that is simple for other programmers.

Rule: Rewriting is acceptable only in a very limited set of situations.

Law: The Law of Testing: The degree to which you know how your software behaves is the degree to which you have accurately tested it.

Rule: Unless you’ve tried it, you don’t know that it works.

Attaching custom exceptions to functions and classes

http://pydanny.com/attaching-custom-exceptions-to-functions-and-classes.html

class DoesNotCompute(Exception):
    """ Easy to understand naming conventions work best! """
    pass

def this_function(x):
    """ This function only works on numbers."""
    try:
        return x ** x
    except TypeError:
        raise DoesNotCompute

# Assign DoesNotCompute exception to this_function
this_function.DoesNotCompute = DoesNotCompute

>>> try:
...     this_function('is an example')
... except this_function.DoesNotCompute:
...     print('See what attaching custom exceptions to functions can do?')
...
...
See what attaching custom exceptions to functions can do?

Node.js testing

http://blog.nodejitsu.com/rest-easy-test-any-api-in-nodejs
http://caolanmcmahon.com/posts/unit_testing_in_node_js/
http://zombie.labnotes.org/

The Pikos Profiling Toolkit - Simon Jagoe

https://github.com/sjagoe/pikos

Test Driven Development for Small Django Projects - Martin Brochhaus

django-nose
django-jasmine

Modules

http://asvetlov.blogspot.com/2010/05/blog-post.html

• package
• __init__.py
• a.py
• linux2
• b.py
• win32
• b.py

Мы кладем "общий" код непосредственно в package, а платформозависимый разносим по вложенным (технически они могут находится где угодно) папкам. Обратите внимание - linux2 и win32 не содержат __init.py__ и не являются вложенными пакетами.

import sys
from os.path import join, dirname
__path__.append(join(dirname(__file__), sys.platform))

Python help, docs, examples

http://www.python.org/doc/
http://www.doughellmann.com/PyMOTW/contents.html - Python Module of the Week
http://code.activestate.com/recipes/langs/python/ -  ActiveState popular Python recipes
http://stackoverflow.com/questions/tagged/python