Showing posts with label python. Show all posts
Showing posts with label python. Show all posts

Friday, March 08, 2019

Please protect the right to create public domain works

snap is a package format for faster release cycle on Ubuntu. Recently its snapcraft.yml description file has got license field:

# License for the snap content, based on SPDX license expressions.
license: <expression>

Which led me to discover corporate looking SPDX website that aims to set standard on package metadata. And this metadata doesn't allow public domain code:

https://wiki.spdx.org/view/Legal_Team/Decisions/Dealing_with_Public_Domain_within_SPDX_Files

I expected that such project would be equally inclusive to protect the rights of people to release their code without copyright regulations. I would expect it to work with corporate and public services to enable this option, clarify its meaning and champion changes in legislation. But instead this Linux Foundation project decides that public domain code is too bothersome to deal with.

Most of my Python code is released as public domain. I like the total freedom of not being forced to deal with strings attached, and I want to give this freedom to people who use my code. I don't even want this code to be "my". I do not need copyright at all. Giving credits to people and supporting those who need support - this activity doesn't need copyright. Technology can make it automated. Being present in copyright header doesn't mean that people care. This problem copyright can not fix.

Copyright was invented before the internet, 300 hundred years ago, before git and Mercurial, and lawyers are still (ab)using it in their legal warfare, turning it against those who could show how we could use technology to build a better world, with less stress and more transparency. With the next generation mentality of the internet children, it is possible to create a next generation of ecosystem with cooperative gameplay and better ecological goals. We really need to ask each other personally - "What do you want? What do you need?" - and help each other grow internally - not externally. Collaborate on building better systems, better code, instead of squabbling on what's already been written.

Starting with myself - What did I want? I wanted recognition. I didn't want money. Copyright didn't help me to get recognition. Recognition came from my social activity, from interacting with people, building open source, collaborating together, trying to solve some problems in a better way. Many years later recognition came from inside. From mindfulness, and that was a huge relief - not trying to compete with people and show off to seem better on outside. Copyright didn't help me to get money - they came from solving problems for other people without adding new ones. Money came as a result of interacting with others over the things that I found challenging and interesting enough.

I've been paid money, because I can not survive without them, and my network was responsive to my need. I didn't write CV letters or applied to job fairs or went by advertisement in factories. Once I've become transparent to the network with open hands to be helpful, the money found their flow to compensate me for my time. In seven years I signed only one legal paper, one contract with NDA, and that was the only case when I was not paid after finishing the job. I don't want to live in your legal network - I want to be left in mine. In the network where we transparent and don't attack each other with long legal "electronic documents" that are just a scanned paper. I want to live in a netowrk where my will is a signed data structure on a public blockchain, where people are connected and understand what being a human is not easy, and appreciate our nature and support each other towards greater goal.

I don't mind people playing the copyright game. People need games to play. But I do not approve it. Suing programmers for their pet projects that got more popular than mundane office project, taking money for access to scientific papers and not paying scientists who produced them. I am tired, I am scared, because I am paranoid, and I want to opt-out from this system.

I needed support and I joined the Gratipay project. In Gratipay I didn't do much, but in the process I learned to support other people. People whose code I like, people I admire, or people who experienced difficulties, or just people who know how to have fun. I started contributing to Gratipay, because it was public domain and it was completely transparent down to the last penny - I could leave at any point and use the code that I learned in my other projects. I tried to make it better and contribute back. I learned a lot and the more questions I asked, the more interesting things I learned. About people, about economics, about financial gameplay. That was an awesome time and a great experience. I wish that everybody in their live could join a project like this. Helping completely open and transparent company. Gratipay could not survive in U.S., and now its public domain code is serving Liberapay in France.

Public domain was the only way to opt-out from copyright, and with the decision to abandon the fight for it, Linux Foundation closes the door for me to share my code with no strings attached. Treating public domain works "the same way as any license" is the worst decision the SPDX project could take. Public domain is in the "conflict of interests" zone of copyright lawyers, because it is about ignoring their domain, about the right not to care about their business and not being touched by their activities. The task for protecting public domain is for true legal hackers, the ones who go beyond compliance to see the people on the other end. Because there is always a person behind Twitter handle or GitHub account and the person means a little bit more than a "copyright holder".

SPDX raised an important point - Public Domain is not copyright. The right programmatic solution is it to add a separate copyright-optout: true field that is mutually exclusive with license, because this semantic is completely different from the paper based kludges and cargo cults of the past. It cleans up the space for the next generation of internet connected people to ask questions - how do we give credits and how do we support other people in the age of technology.

Please fight for Public Domain - it may appear more important for positive development of technology than we currently see, and it may provide a foundation for better bringing us together.
at 2 comments:
Labels: , , , , ,

Wednesday, November 02, 2016

Python Usability Bugs: Formatting argparse subcommands

Suppose you want to build a tool with a simple interface:
usage: sub <command>

commands:

  status -  show status
  list   -  print list
Python proposes to use argparse module. And if you follow documentation, the best you can get will be this output:
usage: sub {status,list} ...

positional arguments:
  {status,list}
    status       show status
    list         print list
And it you implement proper formatting, your code will look like this:
import argparse
import sys

class CustomHelpFormatter(argparse.HelpFormatter):
  def _format_action(self, action):
    if type(action) == argparse._SubParsersAction:
      # inject new class variable for subcommand formatting
      subactions = action._get_subactions()
      invocations = [self._format_action_invocation(a) for a in subactions]
      self._subcommand_max_length = max(len(i) for i in invocations)

    if type(action) == argparse._SubParsersAction._ChoicesPseudoAction:
      # format subcommand help line
      subcommand = self._format_action_invocation(action) # type: str
      width = self._subcommand_max_length
      help_text = ""
      if action.help:
          help_text = self._expand_help(action)
      return "  {:{width}} -  {}\n".format(subcommand, help_text, width=width)

    elif type(action) == argparse._SubParsersAction:
      # process subcommand help section
      msg = '\n'
      for subaction in action._get_subactions():
          msg += self._format_action(subaction)
      return msg
    else:
      return super(CustomHelpFormatter, self)._format_action(action)


def check():
  print("status")
  return 0

parser = argparse.ArgumentParser(usage="sub <command>", add_help=False,
             formatter_class=CustomHelpFormatter)

subparser = parser.add_subparsers(dest="cmd")
subparser.add_parser('status', help='show status')
subparser.add_parser('list', help='print list')

# custom help messge
parser._positionals.title = "commands"

# hack to show help when no arguments supplied
if len(sys.argv) == 1:
  parser.print_help()
  sys.exit(0)

args = parser.parse_args()

if args.cmd == 'list':
  print('list')
elif args.cmd == 'status':
  sys.exit(check())
Here you may see the failure of OOP (object oriented programming). The proper answer to this formatting problem is just to define a data structure for command line help in JSON or similar format and let people dump and process it with templates. Once option definition is parsed, the information there is static, so there is no need in those intertwined recursive method calls. So just do it in 2 pass - get dataset and render template.
at No comments:
Labels: , , , , , , , ,

Saturday, September 17, 2016

Python Usability Bugs: subprocess.Popen executable

subprocess.Popen seems to be designed as a "swiss army knife" of managing external processes, and while the task is pretty hard to solve in cross-platform way, it seems the people who have contributed to it did manage to achieve that. But it still came with some drawbacks and complications. Let's study one of these that I think is a top one from usability point of view, because it confuses people a lot.

I've got a simple program that prints its name and own arguments (forgive me for Windows code, as I was debugging the issue on Windows, but this works the same on Linux too). The program is written in Go to get single executable, because subprocess has special handling for child Python processes (another usability bug for another time).
>argi.exe 1 2 3 4
prog: E:\argi.exe
args: [1 2 3 4]
Let's execute it with subprocess.Popen, and for that I almost always look up the official documentation for Popen prototype:
subprocess.Popen(args, bufsize=0, executable=None, stdin=None, stdout=None, stderr=None, preexec_fn=None, close_fds=False, shell=False, cwd=None, env=None, universal_newlines=False, startupinfo=None, creationflags=0)
Quite scary, right? But let's skip confusing part and quickly figure out something out of it (because time is scarce). Looks like this should do the trick:
import subprocess

args = "1 2 3 4".split()
p = subprocess.Popen(args, executable="argi.exe")
p.communicate()
After saving this code to "subs.py" and running it, you'd probably expect something like this :
> python subs.py
prog: E:\argi.exe
args: [1 2 3 4]
And... you won't get this. What you get is this:
> python subs.py
prog: 1
args: [2 3 4]
And that's kind of crazy - not only the executable was renamed, but the first argument was lost, and it appears that this is actually a documented behavior. So let's define Python Usability Bug as something that is documented but not expected (by most folks who is going to read the code). The trick to get code do what is expected is never use executable argument to subprocess.Popen:
import subprocess

args = "1 2 3 4".split()
args.insert(0, "argi.exe")
p = subprocess.Popen(args)
p.communicate()

>python suby.py
prog: argi.exe
args: [1 2 3 4]
The explanation for former "misbehavior" is that executable is a hack that allows to rename program when running subprocess. It should be named substitute, or - even better - altname to work as an alternative name to pass to child process (instead of providing alternative executable for the former name). To make subprocess.Popen even more intuitive, the args argument should have been named command.

From the high level design point of view, the drawbacks of this function is that it *does way too much*, its arguments are not always intuitive - it takes *a lot of time to grok official docs*, and I need to read it *every time*, because there are too many little important details of Popen behavior (have anybody tried to create its state machine?), so over the last 5 years I still discover various problems with it. Today I just wanted to save you some hours that I've wasted myself while debugging pymake on Windows.

That's it for now. Bonus points to update this post with link when I get more time / mana for it:

  • [ ] people who have contributed to it
  • [ ] it came with drawbacks
  • [ ] have anybody tried to create its state machine?
  • [ ] subprocess has special handling for child Python processes
at No comments:
Labels: , , , ,

Thursday, June 16, 2016

Why Python community should take UX seriously

UX is a discipline that is dedicated to measuring user emotions and satisfaction while using a product in order to improve them. When you grow experience in any programming language you start to experience negative emotions towards small warts and glitches that constantly get in your way. You compare it to different languages and soon you're no more satisfied with it. Backward compatibility etc. doesn't allow to change things, but they should be changed, and UX is the criteria and method to answer how. But why?

People are dying too quickly. The process of learning new technology is fun and exciting, but when you look at the ideas in the past you'll see that we are not inventing anything new. People thought about many ideas, and couldn't implement them. I still don't have automation line that pours me coffee in the morning and bakes omelet and this idea is like 20 years old. I have no information about where my products are coming from - this idea is about 10 years old, and those fruits that are coming from hydroponics and pretty tasteless, so I'd prefer to buy something bathed in organic sun. Where are those inventions now? I am pretty sure somebody is trying to design these things in own basement, but those inventions will never see the light, because they are fragile, needs a lot of experience and education. Why learning is hard? It needs a lot of experience and education to learn concepts, operating systems internals and get used to various glitches and workarounds from the past. If Python was easier, if operating systems were more easy to learn and intuitively understand, not relying on elitist part of hacker culture, we could hack on more fun and reliable things today.
at No comments:
Labels:

Tuesday, June 07, 2016

Why Roundup needs a router?

http://bugs.python.org/ is powered by ancient software. Most people nowadays won't install it. They would rather find something newer, with more features (consumers) or invent something from scratch that will be more modern from the start (makers).

How about trying a different approach - how about an approach that means constant evolution of the software? The reason why people reinvent things from scratch is because they often can not understand the complexity of what was already written. The burden of complexity is like tar that glues us to the surface, needs more force to take a step and slows us down. One way to get rid of it is to start again clean. But there is no guarantee that the same story won't happen if you couldn't see past complexity before.

A way of evolution is to face the complexity and deal with it. The way to deal with complexity tar is to learn to fly over it. Visualization, art, story-telling are helping to people to overcome limitations of our attention, interest, motivation and focus. There are tools to make complex things simple, there are things to look at the surface from above and choose a path that is still unexplored.

Router is a component that directs URL request to processing. Router says that http://../file142 should be processed by function that handles files, and http://../issue42 should be handled by function that processes issues. This logic is hardcoded into Roundup, so its URL structure doesn't change. If Roundup had this router, then it could be used as a replacement for existing trackers without breaking links. Router also allows Roundup extensions add new endpoints, such as ones required for OAuth2 processing or REST and ajax interface.

So, how to evolve software? It takes media and coordination skills first, and code review and design second. Additional code that makes code more complex should be backed up by documentation that explains it, every lengthy documentation that gives details should be accompanied by concise overview and reminder picture, every yak shaving process should be automated, every upstream tools need to be improved. Evolution is a global process, and it is hard (if not impossible) to evolve one agent if the whole ecosystem is not changing. Changing ecosystem or tools that are already stable like Python require process shift that drastically changes how people coordinate, approve, mutate and select the branches with features that comfort them.
at No comments:
Labels: ,

Wednesday, May 11, 2016

Open Source, Death, and Open Economy

Open Source is a great idea, great movement and a great boost to the progress of civilization. Open Data made transparent governments possible, which allowed people to regulate tough problems, not hide them. Open systems like Linux and Open Stack enabled building more useful software on top of more solid and stable basis (first for single operating system nodes and now for clouds and networks).

So why Open Source is dead? Because there is no such thing as software product - any software is alive as long as its code is live in the heads of its maintainers. As soon as maintainers leave, the product enters death spiral - new people enter the field to patch the product to the death. Open Source is dead, because maintaining Open Source software requires time, and every minute of that time you need to pay for food, for shelter, for the privilege to meet with your friends and be inspired. Open Source maintenance does not release maintainers from paying for all this stuff and doesn't bring them those payment tokens called `money`. So code in maintainers heads will have to die.

How come that current economy is so flawed? Does Open Source produce value? Definitely, yes. Does it solve problems for people? Yes. Do people feel grateful for Open Source? Well, sometimes (but that's also the question of consumer culture forced by current economy). And still open source developers leave their products to join (often meaningless) activities of reinventing things from scratch for other projects. Often doing things that they've paid for and not things they know and like.

How come that people with developed skills doing useful things have nothing to eat, and for food and shelter have to reformat their brain and became compliant with office slavery? Sometimes I feel like we should extend software freedom conservancy model from software to people and remove "people with money" from power part of this equation. Blockchain allows us to calculate personal values to remove this money-for-money gameplay. Gameplay that creates parasites out of people, parasites that are motivated to produce garbage, to consume and to battle each other for "market domination". Parasites don't like to be exposed, and they don't like to be parasites, so maybe Open Economy is an answer that can bring our focus back to the planet with depleting resources and increasing pollution that pushes our health and general feeling of the world down to the level of committing a suicide.

I'd like to believe, but I am loosing my insight sometimes. There are many good people who care about me in this world, and this letter won't be there if not them. But their lifetime is limited, and so is mine. I really wanted to boost progress to help with my health and global problems, but it seems I failed. This post is filled under a Python tag, which always was a part of that unconscious plan. I thought that I could enhance it to be an easier, and more intuitive tool to augment limited human abilities for automation, to help them concentrate on more important things. But it seems I failed. I still see things how they should be done, I still see that DX (developer's experience) need to raise to the top of people priorities. It is just that I am exhausted to compete for food and shelter and feel depressed over the need to reformat my natural intelligence network to do those (often meaningless) office things just to keep my body alive.
at 1 comment:
Labels: , , ,

Sunday, January 10, 2016

Reaction to Python development moving to GitHub

If you don't know, the Python core developers are considering move to GitHub, which I believe will abandon Roundup, Mercurial and a couple of other initiatives that some of us picked, because they were used by community and were useful to it. For example I added support for Jinja2 to Roundup, tried to add a new router component for it to enable adding new web APIs more easily, and now I am doing a release of new version, because that package is valuable.

Below is my post sent to https://mail.python.org/mailman/listinfo/core-workflow as an immediate reaction to the PEP that addresses the migration. I think that people need to consider Python as something with much better potential than just "a product to execute computer scripts". I want people to think about it as about open process with all the involved complexity and dynamics issues, a place to study and learn about different culture than following the orders of your owner founder. Some want to see it to be isolated coding playground without all that disturbances and annoying people with external world problems. But it is unavoidable. There are already diversity statement and codes of conducts. It is time to stop being ignorant to economics for the balance.

Blender is a good example. 3D editor that every two years chooses a problem that is actual for community and makes a movie together with building necessary features in the editor. They discuss economics, try to address funding issues by working with funds outside of coding domain, bringing new initiatives, communicating and still staying open - not ignoring the issues and not trying to bring the same hammer on the new "nail". Why Python fails to follow the same route?

I don't know why it bother me that much. Probably because I am jobless and living in northern country where you can't live on street and need to pay rent, so "getting paid for the useful stuff that you do" is extremely important issue for me. But also I feel that my time is limited, and that it is very sad to spend my life behind the screen of computer, reinventing some code that was written numerous time for a company that can not support something that is already written.

I realize that with reduced exposure to a projects like Roundup and Mercurial it will be much harder (if possible at all) to gather critical mass of resources around people to experiment with sustainability models for open source, and doing these things is important, because we coming into the age of extremely powerful automation where people may not be that needed anymore. For me open source is the only way to gather data on what will happen, and maybe the only way to find the balance. Open source economics right now is when resources are limited, but there are many people how could use them, but if they use them, others (who probably can do better) may feel bad about this. This is a just a single problem that needs to be addressed in the process, and I wish that there could be that sustainable working process in the list.

Here is original mail sent:


Read more »
at No comments:
Labels: , , ,

Thursday, September 03, 2015

SCons build targets

SCons is awesome. Just saying. If you want to know (or troubleshoot) how SCons selects targets to be built, add this snippet at the end of your SConstruct:
def dump_targets(targets):
  for t in targets:
    if type(t) == str:
      name = t
    else:
      name = t.name
    print("  <" + str(t.__class__.__name__) + "> " + name)

print("[*] Default targets:")
dump_targets(DEFAULT_TARGETS)

print("[*] Command line targets:")
dump_targets(COMMAND_LINE_TARGETS)

print("[*] All build targets:")
dump_targets(BUILD_TARGETS)
For my copy of Wesnoth, 'scons .' produces this output:
[*] Default targets:
  <Alias> wesnoth
  <Alias> wesnothd
[*] Command line targets:
  <str> .
[*] All build targets:
  <str> .
And if you want to know how to specify targets or what do they mean, read the second page of SCons man documentation. Just for convenience I quote it here.


scons is normally executed in a top-level directory containing a SConstruct file, optionally specifying as command-line arguments the target file or files to be built.

By default, the command
scons
will build all target files in or below the current directory. Explicit default targets (to be built when no targets are specified on the command line) may be defined the SConscript file(s) using the Default() function, described below.

Even when Default() targets are specified in the SConscript file(s), all target files in or below the current directory may be built by explicitly specifying the current directory (.) as a command-line target:
scons .
Building all target files, including any files outside of the current directory, may be specified by supplying a command-line target of the root directory (on POSIX systems):
scons /
or the path name(s) of the volume(s) in which all the targets should be built (on Windows systems):
scons C:\ D:\
To build only specific targets, supply them as command-line arguments:
scons foo bar
in which case only the specified targets will be built (along with any derived files on which they depend).

Specifying "cleanup" targets in SConscript files is not usually necessary. The -c flag removes all files necessary to build the specified target:
scons -c .
to remove all target files, or:
scons -c build export
to remove target files under build and export. Additional files or directories to remove can be specified using the Clean() function. Conversely, targets that would normally be removed by the -c invocation can be prevented from being removed by using the NoClean() function.

A subset of a hierarchical tree may be built by remaining at the top-level directory (where the SConstruct file lives) and specifying the subdirectory as the target to be built:
scons src/subdir
or by changing directory and invoking scons with the -u option, which traverses up the directory hierarchy until it finds the SConstruct file, and then builds targets relatively to the current subdirectory:
cd src/subdir
scons -u .
at No comments:
Labels: , , ,

Sunday, August 16, 2015

Technical Debts for Python Community

Debts and credits is a new age slavery. Technical debts are better, because they are just a disease. It can fatal if not treated, but for a strong community it is not a problem. Still a good working plan and a vague roadmap is needed to coordinate many eyes to go in the same direction and push things forward where it is hard to reach a consensus.

Dangers of Technical Debts


Technical debt is hard to understand and identify, but once your know about it, it will be easy to spot those things early. The most common symptom of technical debt is stolen time, which if not treated becomes a paralysis. You may know how your system works, and all the components, and where the files are, but you also have the previous experience about how much time it takes to modify and properly test the system, and ensure that everything is correct, and you just know that you just don't have the time, because your family and friends are missing you. We are all volunteers, etc.

Recipe: Simplify Your Systems, Reduce the Complexity, Automate Things and Think in 15 Minutes Slots.

Thinking in 15 Minutes Slots

This may not be so important for enterprise projects where people exchange their time for money, but my opinion is that it is extremely important for open source projects where time is distributed over many people.

Have you ever wondered what will a highly talented person be able to do for Python if we are lucky enough to get 15 minutes of his or her attention?

I am afraid that the sole "contribution" would be making a checkout. Even correcting a mistake in documentation requires that. Maybe the most he or she could accomplish would end in setup of Git or Mercurial. And if the checkout is a long and boring, the person may lose interest and switch to something different even before 15 minutes are expired.

I will continue with how technical debts are evolving into Competence Debt,  but first.. let me take a selfie tell a story. Just to complete the 15min section, I once accepted a challenge to make a design fix for Launchpad. I spent 15 minutes 4 times - an hour - and couldn't even get the checkout. Here are the sessions:

FAIL: edit wiki - move bzr instructions to the top
send a letter to https://lists.launchpad.net/launchpad-dev/ that wiki pages are not editable
Yes, I got distracted during the first session, but I want to make the world better by fixing things on the way. Of course, I'd like those problem not to appear in the first place. Let's see how a next session ended.

# create LXD container for experiments
$ lxc init ubuntu lp
$ lxc start lp
$ lxc exec lp -- bash
# apt-get install bzr
# bzr branch lp:launchpad

The second slot was all about reading instructions and setting up "virtualenv for Linux" to install all the prerequisites without polluting my main system (and drop them without consequences). I already knew about LXD, so my competence here was already high to save some time on learning that. BTW, LXD rocks. Just try it.

# cd launchpad
# apt-get install postgresql make
# ./utilities/launchpad-database-setup $USER
# make schema
FAIL: many errors
# utilities/update-sourcecode

These 15 minutes left me in confusing state without any working instance to get some positive feedback on what I am doing. At this moment I already have a strong desire to just drop everything. And yet after some time I get back to spend another 15 minutes slot trying to tackle the problem.

# drop old LXD container
lxc delete lp
# create new LXD container
lxc init ubuntu lp
lxc start lp
lxc exec lp -- bash
# install basic dependencies
apt-get install bzr make postgresql wget
bash rocketfuel-setup
# ^ need to enter name, and click Y on Apache install prompt
FAIL:
  Making local branch of Launchpad trunk, this may take a while...
  You have not informed bzr of your Launchpad ID, and you must do this to
  write to Launchpad or access private data.  See "bzr help launchpad-login".
  bzr: ERROR: Connection error: Couldn't resolve host 'bazaar.launchpad.net' [Errno -2] Name or service not known
  ERROR: Unable to create local copy of Rocketfuel trunk
# attempt to repeat the script
bash rocketfuel-setup
FAIL:
  bzr: ERROR: No WorkingTree exists for "file:///root/launchpad/lp-branches/devel/.bzr/checkout/".
  ERROR: Your trunk branch in /root/launchpad/lp-branches/devel is corrupted.
         Please delete /root/launchpad/lp-branches/devel and run rocketfuel-setup again.

Now I really drop it. So after that user experience I doubt I will ever get hacking on LaunchPad again. So, if your technical debt provides poor experience for onboarding users, you're likely to lose them for a lifetime.

The Debt of Competence


Competence Debt is a chronic phase of the Technical Debt illness. When time for operation become more than your daily limit, there comes paralysis, and after that the worst thing that can happen is when you no longer know how your systems work and lack skills to restore the picture.

From that moment your project is entering the death spiral and it is only a matter of time when it will be dead. I've seen several examples where programmers was treated like a replaceable material, but the truth is that program lives as long as its code is alive in the heads of its maintainers. There is no such thing as "a software product" anymore - software is more about support and development, than about selling products on a local market.

For open source projects competence debt usually results in various rewrites and long term stale issues. Many attempts to fix them, many hours wasted just to hit the wall with new heads over and over. The power of open source is a little time and little effort that is distributed over many people to create momentum. That was the original idea behind the rainforce.org domain when it all started many years ago. And it is also the result of OpenStreetMap success - small and clear activities that don't require much time and competence to accomplish. This scales well and provides a good gameplay.

Recipe: Invest in Visualization and Learn Visual Tools (SVG, D3.js, Inkscape) to Explore Ways to Transfer Your Competence to Other People

Text is not a natural way for people to consume and produce information. We learn how to read and write, and it takes more than a month to get used to it. But learning to play games like World of Tanks just takes a few minutes. The new generation that I am a part of is used to watch YouTube lectures on 2x speed, read only first 150 letters of the messages and scan long texts without actually thoroughly reading them. That's why I highlight the key points in this post. We were developing tools for audio/visual communication naturally over all these many years - 3D graphics, demoscene, virtual reality, and now deep learning networks, but we still find it hard to produce visual material for communicate other ideas. Because we've been taught to write text, not to produce beautiful art that just works. Learn to draw. It makes people happy learning something new.

OpenStreetMap - The Earth as The Outline


Here is a success story. No, it won't teach how to remove technical debts, but rather give an idea how to restructure it, so that a thousand eyes could make an impact.

The OpenStreetMap has a reference model - it is our Earth. We just copy what we see into vector form to draw a map and everybody could validate with their own eyes. With open source project it is all the same, except that you need to create that reference model and that should be actionable -  split into many pieces that people can validate in parallel separately. Think about specification where every is independent enough to serve both as an entrypoint and a clause to put a checkmark next to it if a condition is true. Think about a canvas, where everybody can draw the common vision and then see who has drawn the components that they can reuse in their own sketches. The reference model is what you need to know where to push so that your small effort could contribute to a greater goal. The Roadmap also tell you where your skills will be more useful, and ensures that your efforts will not be wasted

The Role of Foundations


People think of foundation as of fund. That's not effective. I need about $600/m to cover shelter and food expenses. Travelling, buying clothes and stuff, covering medical expenses raises the plank to $1000/m, girlfriend may add another $500/m, building a house another $500/m, and I don't even want to think about children. There is no chance I will be able to afford this. So at a bare minimum a foundation should provide $600/m per person to deal with EPIC issues that nobody could deal with in their spare time. Forgot the taxes. Add another $600/m on top of that, and that's just one person, and you need at least two of them. So, $2400/m just to make router for https://bugs.python.org/ so that we can add more URLs endpoints via extensions for interactive frontends and  REST API to it. Nobody will ever pay for that. We tried to hack the problem with Gratipay, but got a flashback from a protection mechanism of U.S. financial system. It is clearly a dead end to fight the World owned by corporations (the World as it was already 100 years ago).

Instead, the role of the foundation is to explain to corporation the above mathematics of time and effort, to enable people in these companies give more time to contribute their professional expertise to deal with complexity and reduce competence debt for the community. Applying the recipes to reduce the technical debt to inspire people. Employing art for documenting the systems and structures, so that people could digest the information easily. Organising in-house sprints to deal with important matters we alone, with less time, but many hands can not tackle on our own.

The role of foundations is not to empower individuals, but collect the data about obstacles, foresee and communicate about them on the path ahead, and organize clean up efforts where they are needed, so that anybody who got those precious 15 minutes knew what to do, and could spend those 15min most effectively to bring their contribution to the common stream that benefits everyone.

at No comments:
Labels: , , , , ,

Sunday, June 21, 2015

Lifehack - import directly from command line

If you're obsessed with UX as I am, and long repetitive commands seem to break your flow, you may appreciate this little trick for invoking Python from command line.

I invoke python from console/terminal to check some behavior that I tend to forget after a day in JavaScript or other programming languages. It is often way faster than reading the docs. It also helps to quickly try new PyPI libraries after installing with pip (saves on mouse clicking in IDE etc.).

Today I found a time saver that makes me happy. This example is typed for Windows, but there should be no problem for any Linux hacker to port it to their favorites. So instead of doing this:
> python [ENTER]
>>> import os [ENTER]
>>> os.name [ENTER]
'nt'
I can just type:
> import os [ENTER]
>>> os.name [ENTER]
'nt'
It should be now easy to understand how it works, so I will complicate it a bit. The trick is this little import.bat script, placed in system PATH:
@echo off
py -2 -c "import sys; print(sys.version)"
py -2 -i -c "import %*"
py here is a py.exe launcher that can call either Python 2 or Python 3 depending on argument. It comes installed with Windows Python versions. I like to know which Python I work with, so I've added version into to the command, and to avoid polluting the global space of new interpreter, the version is printed by separate command.
at No comments:
Labels: , , , , , ,

Sunday, May 03, 2015

ANN: patch 1.14.2 - utility to apply unified diffs

Google Code shutdown kicked me to finally release the Python patch utility on PyPI.
  • Python 2 only for now (issue #10)
  • single patch.py file that can be dropped directly into your repository
  • command line tool
  • importable diff parser library 
  • doesn't create and remove files (issue #3)
It can be run in from command line standard way
    python patch.py <patch.diff>
or directly from .zip file:
    python patch-1.14.zip <patch.diff>
Get it from PyPI: https://pypi.python.org/pypi/patch
at 1 comment:
Labels: , , , ,

Monday, March 09, 2015

Python CLA, Community and Node.js

I was trying to write on CLA multiple times, since the day that I sent "My CLA" letter in hope for some explanation to python lists. Now search for "My CLA" leads to new model of Mercedes Benz released in 2014 and I wonder, why do I waste my time arguing on the things that should not matter to me? Why do they matter at all? If I could afford a Mercedes Benz and had time to enjoy it, everything else probably didn't matter.

https://www.joyent.com/blog/broadening-node-js-contributions

The post by Bryan Cantrill is all good, but this quote in particular got my attention:
While node.js is a Joyent-led project, I also believe that communities must make their own decisions—and a CLA is a sufficiently nuanced issue that reasonable people can disagree on its ultimate merits.
I don't  remember that steps were taken to explain the necessity of  CLA or ask people what they think about it. There was no community process that I've seen and my requests to get some clarification did not went good. It took months of non-constructive critics and diplomatic skills of Ezio to at least add electronic signature to the paper form. There was no incident, nothing in public to cover that. Just somebody decided to do this and then there was a lot of peer pressure to force you to comply, because "lawyer know better". I can hardly name it a community process. OpenStack fights for it, to keep process open and inclusive, tries to analyze problems, to seek solution in open way, at least it is visible.

http://lists.openstack.org/pipermail/openstack-dev/2015-February/056551.html

Python was an open source language, and a good and unique one that deserves its own license. Guido is always open and sincere behind the community of language supporters, but are languages supporters evolve the same, do they possess the same understanding into the complicated nature of human processes to take the baton? Did the core of community become a closed elitist circle of people with good relationships? Are they able to handle the insane amount of ideas and communication that coordination around core development and surrounded infrastructure is needed? Is new generation involved in solving these challenges or all they do now is dreaming about startups? Is it a community problem or economy problem already with all these CLA and other issues that are impossible to hide?

https://mail.python.org/pipermail/distutils-sig/2015-March/025807.html

at No comments:
Labels: ,

Monday, February 16, 2015

ANN: hexdump 3.2 - packaged and pretty executable

https://pypi.python.org/pypi/hexdump

The new version doesn't add much to the API, but completes a significant research about executable .zip packages with proof of concept distribution that is both an installable Python package that you can upload to PyPI and an executable .zip archive.

The benefit is that you may drop .zip package downloaded from PyPI into your source code repository and invoke it from your helper scripts as python hexdump-3.2.zip Keeping dependencies together with application source code in repository may seem like a bad idea, but we find it useful at Gratipay to setup project from checkout in offline mode with no internet connection.

The solution required three modifications to distutils setup.py (see sources):
  • force sdist command to produce .zip file
  • strip extra dir created at PyPI package root
  • add __main__.py to make .zip executable

If you think that it is cool and should be promoted further, feel free to test Gratipay to send me 0.01+, and I'll get the signal to spend more time on reversing native distutils/packaging gotchas.
at No comments:
Labels: , , , , ,

Thursday, January 08, 2015

Shipping Python tools in executable .zip packages

UP201501: Found out how to force setup.py create .zip instead of .tar.gz

This is about how to make Python source packages executable. As a side effect, this also explains, how to run invoke's tasks.py with a copy of invoke .zip shipped with your source code, but without installing it.

You know, Python can execute .zip files. As simply as:
$ wget https://pypi.python.org/packages/source/h/hexdump/hexdump-3.1.zip
$ python hexdump-3.1.zip
/usr/bin/python: can't find '__main__.py' in 'hexdump-3.1.zip'
Well, you need to place '__main__.py' into the root. It will then import what it needs and do something. The only problem with .zip source packages is that their structure (if created with standard Python tools) includes one additional directory at the top:
`-- hexdump-3.1
    |-- PKG-INFO
    |-- README.txt
    |-- hexdump.py
    |-- hexfile.bin
    `-- setup.py
So, even if you place `__main__.py` into the root, it won't be able to import file from `hexdump-3.1` subdirectory.. unless you prepare for it. Here is the solution:
import os
import sys

# add package .zip to python lookup path
__dir__ = os.path.dirname(__file__)
path = os.path.join(__dir__, 'hexdump-3.1')
sys.path.insert(0, path)

import hexdump
msg = hexdump.dehex("48 65 6C 6C 6F 2C 20 57 6F 72 6C 64 21")
print(msg)
Now if you run it, it will print the obvious.
$ python hexdump-3.1.zip
Hello, World!
In Python 3, the result will be wrapped into b'' string. But that's it!

The next hexdump version will likely to ship as executable .zip package

Where you may need it?


It may be useful for scripts automation if you're "vendorizing" dependencies (ship them with your code). It started with need to fix a broken link on Gratipay site. The Gratipay codebase is in public domain clear of any NDA, CLA and all other BS, and that makes it great for people to learn, reuse and enhance. I wish Python internal projects possessed these properties, but PSF politics is another topic.

Gratipay inside site uses make. It doesn't need powerful build tool, such as scons, so I tried to replace it with some simple task automation utility to be more cross-platform. I chose invoke, because of my previous experience with fabric for remote control, and because I saw previous attempts in another Gratipay repository. The necessary condition for new tool is that user experience should not degrade for make users, so main invoke's tasks.py script needed to be self-executable.

I completed the proof of concept by making invoke .zip package executable with the method above, placed it into vendor/ directory, and tuned tasks.py to reexecute itself with invoke .zip This also solved a potential problem with currently unstable invoke API.

tasks.py was modified as following:
import sys
sys.path.insert(0, 'vendor/invoke-0.9.0.zip')

from invoke import task, run

# ... tasks go here

if __name__ == '__main__':
  import sys
  from invoke import cli
  cli.main()

Bonus points


There is one more thing, which is better explained with hexdump example. hexdump package ships `hexfile.bin` data file used for testing. hexdump.py looks for it in its directory (__file__ dirname), and this lookup fails when hexdump.py is in archive. I'd say Python could provide some kind of an API to deal with "virtual import filesystem" (with watchers to track who and when modifies sys.path), but I digress. If you modify the `__main__.py` from the first chapter above to run tests - just call hexdump.runtest() - the execution will finally fail with the following error:
Traceback (most recent call last):
  File "/usr/lib/python2.6/runpy.py", line 122, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib/python2.6/runpy.py", line 34, in _run_code
    exec code in run_globals
  File "hexdump-3.1.zip/__main__.py", line 13, in
  File "hexdump-3.1.zip/hexdump-3.1/hexdump.py", line 311, in runtest
IOError: [Errno 20] Not a directory: '/root/hexdump-3.1.zip/hexdump-3.1/hexfile.bin'
(yes, I am hexdumping under root). The problem above was explained by Radomir, and I feel like the post is already tool long to write about it myself.

More bonus points


In theory it is possible to hack setup.py to produce executable source .zip package. By default, setup.py sdist command on Linux creates tar.gz files. So, first it needs to be forced to create .zip file. This can be done by overriding default --formats option:
# Override sdist to always produce .zip archive
from distutils.command.sdist import sdist as _sdist
class sdistzip(_sdist):
    def initialize_options(self):
        _sdist.initialize_options(self)
        self.formats = 'zip'

setup(
    ...
    cmdclass={'sdist': sdistzip},
)
I posted relevant documentation links to this StackOverflow question. The rest - how to inject __main__.py into the root of packed .zip - is yet to be covered, and I am not ready to research it just yet. Some hints may be provided by these answers.

Usability conclusion


I am actually quite happy with the ability to execute python .zip packages (which gave a lot of motivation to write this post), because previously I had to care about how to tell people that a tool is a single script, which can be downloaded from repository or from some dedicated download site (I mean Google Code, which does not support this anymore). I also don't trust my own server for downloads, because one day I found some "benzonasos" running there and I don't even have a slightest idea how it got there.

But now it becomes possible to just download and run the stuff from PyPI to test how it works without messing with creating and activating virtualenvs, and installation of package inside. Of course, if your .zip package has dependencies, they still need to be present on your system, but that's still a time saver. Oh, and that means that my tools can now consist of several modules inside.

at 7 comments:
Labels: , , , , , , ,

Monday, November 17, 2014

C/C++ Must Die

It is a four hour forward only text. I am not in the mood to clean. reread, refactor, split or fix any mistakes right now, and I am not saying sorry for that, because it is how it is written with this limited keyboard interface that I practiced over my lifetime. I am sorry only if you won't be able to read or understand that, because it would mean I made it all worse. I am already at the point that I want to filter it straight to the subject, reread and fix all typos, obscure moments, digressions and words, but I've already out of time and it might happen that there won't be any time for that later.


My system background is [assembly] --> [pascal] --> [c] --> [php] --> [python], so C is not my favorite language, I am in any way attached to it and don't exhibit a feeling of nostalgia and deep sadness when thinking about what changed in the past 40 years that passed since its invention. What I really regret is that there is no a place like Bell Labs anymore that could prevent bloody enterprise from formatting people to the bloody business mindset. Formatting so badly that you even need a ton of startups to just produce ideas (not mentioning getting them right).

So, in the past 40 years, a new language appeared called Python. I don't think that Guido knew the words "usability", "user experience" or CJM when inventing it - it was just natural and human like, just because it was not engineered, but made through feeling of a human, who likes Monty Python and doesn't follow accepted rituals of human organisms in suits. I understand his desire to keep CWI copyright in place - it is a living reminder about another environment that made this thing possible. Unlike these bloody corporations that keep pressure on what you need to do and when to deliver. There is not much creativity and freedom right now. Those tiny groups of people who gather through the internet try to change the things. But the poor expressive power of non-native English language, time gap and invisible mood and attitude changes make it almost impossible to provide a stable communication channel that will not limit itself only to a narrow band of appreciation, joy and positive emoji. All negative emotions, drama, critics and depressions exists there for a reason - to express the importance of details and adapt them.

Accepted rituals of human organisms in suits. It is hard to be human. So hard that the rational part of us will never accept the idea that I, me, myself are limited. Humans had somehow devised the ethics, culture and rituals to deal with that. Implemented complex system of oppressing behavior and enforcing rules to make everyone the same and keep balance. Capitalist economy made it possible to compete, to make a gameplay to measure and estimate your value compared to someone else instead of just killing him, because his will to live just dampens yours. Money had been chosen as a universal way to solve conflicts and it worked for a few generations. Until a new generation appeared that didn't not care about conflicts and didn't see why would anyone should conflict if everything you need is money. We are still limited humans who fail to see the balance and yet we are trying to prove that we are the best, we need to be respected etc, etc. Whatever our rituals are, they are a shroud on on our eyes. The shroud that doesn't allow us to see how human really work, that our perception is not discrete and the expressive power of art is something we should explore as a discipline of human interfaces.

C/C++ is one such interface. It is a written language that no civilization from the outer world will be able to decipher. I didn't research this idea to far, so I leave it to you. It is a formal interface with brackets, asterisks and letter combinations that convey some ideas and concepts. It brings the former poor language of assembly to a whole new level. The level of more toys to play with and *exchange*. Every language invented after it was adding or removing these toys for humans to play with, but they still have hard time to combine all programming languages into the garden of toys as a whole. The garden that you can explore with the rest of your senses (further that arithmetic and text processor units in your head) to see how things work, tear them apart, which toys go well together and which just don't belong. There should be right toy for the game. It is in our mindset. We use the toy that we've used to, learned the first and like opiate, it instills us with the knowledge that this is the best tool in the world, in your world, because everything else if perhaps just worse. The nostalgic feeling brings us emotions, knowledge and experience keeps us in a comfort zone. Egoism. We want to world to be the same. But while we were playing with our toys, it changed.

Many toys appeared and vanished. Patterns made some of us high. UML - the art erased out of drawing - made slave drivers happy. These were adopted ways to transmit the knowledge, format the culture, and narrow the communication down to the limited capabilities of any human put into the bloody cage of enterprise machine. Bloody doesn't mean we can escape it. It is just bloody. I see it as squashing the humans into the cubes of comfort zones and I am afraid of it. There is no progress outside the cells of enterprise organisms and these organisms are still mostly parasites hooked on resources that they are extracting from ecosystem and killing the planet by their exhaust. If you think that Google is good - take a look to the streets - if there is any litter around - how do you think - could people from this Enterprise remove this litter with their bare hands? I think they could. It is easy and even fun. But will they?

C/C++ is not a litter. It is a tool and a toy. The world had grown a lot, but the tool and the toy stayed the same. In these 40 years we've learned that we can only have juggle 7 things in our head at a time. We have only 60 hertz in out heads compared to 3Ghz of modern CPU. 7 things is the most that can survive through the neural network while signal passes from one domain (limited 3D area) through the whole volume of absolutely parallel processing unit. The amount of thing that we need to keep in mind is bytes, chars and pointers, even for string processing. And as a humans we operate with strings. Even bytes in our heads look like hexadecimal and we are still constantly ignoring this. We are continuing to invent rational logical abstractions - new toys - instead of switching off the conscious part of our brain and concentrate on the part that scans things. In the past 42 years we've upgraded our interface from reading to scanning and nobody noticed that. The older people still insist on reading books, going through lengthy letters in mailing lists, and lots of articles. But we've invented movies, animation, visual arts, demoscene. The last one appeared and vanished - it was a sudden ray of warm and bright light - an excitement that was impossible to rationalize and explain, and that gave a birth to a whole generation of game designers out there.

C/C++ is not a game. It is a legacy, a hack, a combination of mysterious symbols that make impossible things possible. This combination has expressive power and concepts that will survive a whole new generations from now on. You will still need an instrument to manipulate memory on low level. An instrument to control hardware with high level concepts. But it is not C/C++ that needs to be used for that, because it doesn't make it optional. C/C++ doesn't help you scan programs faster, read operations behind combinations of asterisks, symbols and brackets to fill the 7 slots in your head with something that makes sense. It doesn't instill me with a sense of confidence, because the code once already written may leak in different places.

Back in a days we were playing with reversing the software. You choose the entrypoint and then try to figure out what software does. Most of the time you had to work with assembly, follow the jumps and procedures, you were writing tools to help you deal with the complexity and automate the journey. The process didn't change since. What changed is that you don't need to think about memory allocations anymore, algorithms can tackle strings more efficiently than humans, so this slot is freed too. You can concentrate on your DNA handling logic, on algorithm, on final result that you need to achieve and this result will make sense for ordinary humans,  not for people with computer science camp behind. Python made this possible by providing this interface for humans when hardware allowed that. Python adapted itself to humans who now scan things instead of reading them. You don't need a whole usability discipline to note a small nifty things to make improvements like these, but when you have this whole new usability and ux buzzworld emerged, it is somehow wrong not to take an advantage of that. It is quite natural and right from the point of standard human specie, but wrong from the point of augmented human that needs tools to be evolved to allow more freedom. Evolution in Python led to the Zen of it. It is not a speccy, not a book, not a long text in a foreign language. It is an artpiece - a thing that could only be born among people who value the artpiece of Monty Python, and appreciate irrational culture of humans and play that. Without the art squeaky PyPI will be remove and the new warehouse will be built, welcome sign will be replaced with patent paranoia, you will have to sign a paper and undergo passport scan to pass through. People attempt to save things that are important to them if they can see them. You can't see the irrational, you can't explain it, especially things that came naturally. Humans are limited in understanding things, in expressing things, complex associations and irrational thoughts that came out of their emotions, knowledge, fears and beliefs. They are limited in their ability to share this information with others, they don't have time to pass info anymore, can't communicate so fast and this is where the progress stops. Humans are limited, they can not deal with the complexity, and they naturally developed arts to deal with that. Arts communicate on different levels of perception and education, they are waiting for you to get there to feel them or came down on you rapidly right away. It is a way to look for answers, to explore, express and communicate them. It is about at least some kind of freedom in dealing with paralysis of complexity. But this is about C/C++ and I need to finish this.

C/C++ is insecurity, but at the same time it brings trust and freedom. At least it was many years ago. It is the last piece of freedom that makes hacking of the systems possible. It was fun and you don't want to kill the fun once you're there. It is not hackers, it is humans, sometimes among them, who kill the fun. Paranoia, fear, social engineering techniques that make talented hackers kill themselves. It is not fun anymore to hack things in this world of fight of limited species over limited resource. Perhaps the backdoor needs to close. I feel deep sadness and sorrow by thinking about that, but who cares anyway. There is a huge demand for a better readable human interfaces for controlling new technologies and devices that will be born to augment humans and while we are messing with bytes and pointers leaning of some memory scattered over the table, we skip the cosmos of possibilities and things that shine in depths behind our necks. There is a place for better coupling between human intention to care or not care about low level details, better interface between the though to operate on some level and the tools that make the thoughts real. It is important to keep it human oriented, because the picture that one human drawn should be intuitive and clean for other human to comprehend. If that second human is familiar with concepts, it should not undergo the long training in decyphering glyphs just to get into details. We've already seen that this is possible. Just need to experiment with this a little bit more to pave our way in the way art does it. Art is the ultimate hack of all times after the science.

And for us, for new generation of coders, C/C++ must die to let evolution continue.
at No comments:
Labels: , , ,

Thursday, October 09, 2014

Domain disaster, identity, history, account balance and horizons


I've added Python tag to this post, because the traffic above is mostly Python related, so it might be interesting to those concerned about preservation on their posts (or about essential properties of well-known trolls in certain communities). Blogging is not an easy process, especially if you're not an English native and it takes about 4 hours on average to rewrite and reword the content until it satisfies you, so preserving this knowledge is somewhat important. Some of the most emotional and big posts are never published at all (like black hate of Python 3 default system encoding or drafts of Spyder plugin architecture) .

So, what happened with the graph above?

With zero income over the past 2+ years I couldn't keep up with my bills and the domain name registration expired after I couldn't make it. It doesn't cost much ~$10 a year, but it is on the bill with DreamHost web hosting plan that costs $120 yearly + minimal VPS instance for $5/month to run Bitbucket mirrors and other services. I got the money from a $500 gift that I wanted to make to my girlfriend after we broke apart. To be honest I never had a girlfrend, but it was a nice try. It was painful, but in the end these $500 helped to save on debts without sacrificing my desire to meet with friends. I must say it is really hard to sustain any kind of relationship (timely replies, calls, switching to the context of another person, sharing interests, job activities) when you have an ADHD mindset, especially in those moments when you "catch the flow" and just escape everything outside until the feeling passes. The escape is possible. Otherwise it would be a direct way nowhere, but it is always stressful and takes its toll on psychosomatic resilience (how much stress a person can handle until it starts to grow on person's in physical form). Other factors may be contributing too, such as wiring scheme in ADHD trained brain - which can be more flexible so that it is able to diverge resources from maintenance of body systems to cognitive abilities. If there is some virus or generic modification in your body (chronic disease is also an option) - it might (probably will) take this chance to capture more territory when under a stress condition. At a time when rewiring process switches off lights in corridors near the dark corners of immune system. But that's is just a theory, an indication how easy it is for me to become distracted, which in turn is the cause why the situation emerged at all.

Looking at the chart of traffic I think that if that traffic was in any way useful at all, I wish it could be directly converted into paying for domain name and hosting. I don't need extra and don't want to "monetize" content by introducing pestering ads and other nasty stuff from the "business end" - just need the power to keep the systems up and operational. It is quite sad knowing that only a year needs to pass after you die to erase traces of your work from the internet, and even web.archive.org don't help when new owner of your domain uploads robots.txt to block resource-sucking spiders. It will be much more comfortable knowing that what you do will persist to help somebody else save some time in future.

The easy answer would be to just blog on *.blogger.com *.wordpress.com or facebook if you like, and that's already an option for a newer generation, but you own domain is one of the achievements in the ladder of your technical skills. Or sometimes it is just matters for some reason.

One high tech idea to build a sustainable human-less domain preservation mechanism was to build a closed loop around automated recurring payments with bitcoins. That one needs a lot of time to develop and clean up roadblocks for an automatic chain that transforms useful traffic to Etherium or any other similar Bitcoin 2.0 concept. There are two concerns here. First is that useful needs to be defined more clearly. I am sure for some reason that Google already knows and calculates the metric even for posts without views, likes or +1 buttons. Second concern is that there is so much buzz about Bitcoin 2.0, that it looks like people are already fighting to capture this playfield, and I am not sure that these new technologies are really worthy. Investigation and review needs time and it is hard to tell how much exactly without trying.

Another option to sustain the costs was to use DreamHost referral system that through a referral link allows to get bonus for every newly registered user. rainforce.org is a very old account - it uses a deprecated recurring bonus scheme, that shares 10% of new user's payments instead of one-time bonuses, but so far I had only $5 from 10 people registered over last 5 years or so, and I don't think it is a good route to take unless you want to force people to hate you, because you're obsessed with selling them to DreamHost as referrals. rainforce.org also possesses a nice looking donation URL that looks like http://www.dreamhost.com/donate.cgi?id=3333 but it does not answer the questions "how much does this this blog needs to be alive and why?", "what part of a share should I pay?" and more import "why should I pay for this?". In other words there is no transparency and trust in "modern" economy, because openness and transparency hurts it. And if resources become scarce, the economy starts a killing cycle. It is not from economy - it is from ecosystems.

There are always ideas for new experiments and horizons in this area, such as marrying Gratipay concept with BitHub. These project are less obsessed with "doing money software for the money", but they can not escape the "preferential attachment" of people around it, meaning that people will support projects that support money movement more than projects that need actual support, such as PyPy, Spyder and PySide. It might be not even about project support, but more about people contributing to these projects. I don't think that I have a solution to the problem, because it complex, but I think I'd be happy to try if I had a chance.

I tried to submit a proposal for rainforce.org activities to H2020 program as a last chance to escape the corporate clutches and dedicate some time to experiment, but I could not find a single idea over which to subscribe myself to work over for the next five years. In the end I realized that I am alone and hardly the right the right person to do coordination and communication work even though it might be extremely interesting at some point (and hence extremely difficult to resist).

So, in the conclusion of this letter to make it more useful and worthy of 4 hour time, I'd really like to see more people from hard core Python projects that are somehow supported in Europe (such as PyPy and PySide), and especially people from outside who interested in helping them, to take a look at the Horizon 2020 program. It is a funding scheme for EU companies, but organizations from outside (including US and Russia) are welcome to participate with their own funds if they contribute something unique. I believe it is the only way for independent R&D to continue and it will be a pity to miss this chance to experiment with transparent economy schemes and trust systems to support people in open source and open science projects. And it requires more than just coding skills to handle. In fact, it may require a completely different set of skills, even art or design or cognitive sciences - everything that helps better understanding and communication. Because all problems in the world are the problems of communication.
at No comments:
Labels: , , ,

Friday, August 15, 2014

ANN: sha1 1.0 - command line tool to calculate file hash

Windows doesn't have a native tool to calculate SHA-1, so I've made one that can be easily installed and used from command line on any operating system thanks to Python:
python -m pip install sha1
python -m sha1 <filename>
at No comments:
Labels: , ,

Saturday, May 31, 2014

Python 3.2 has some deadly infection

Another not really positive low quality post, so if you're not in a mood to hear some rants, just skip it.


I don't consider talks about different programming languages to be blasphemy. Quite otherwise - they are good to let you rethink what you do daily in your own language. In a recent discussion about languages (and after many fruitless attempts to compile Wesnoth with GCC on Windows) I thought that C/C++ must die, because really all major security problems are because of it. Memory problems, reinventing the wheels, wasting time in Makefile's and Autoconf / Visual Studio project files. Everybody is just forced to use it, people feel like they've become an elite by learning it, but in fact they are just wasting time. Well, you can't blame people for that. Everybody entertains in a way he can, and me while writing this post too.

Yes, early hacker's culture is still here, but is it here to hack on real world problems anymore? NumPy, SciPy, PANDAS, BioPython - this is the example of tools that modern hackers use. C is only useful to speed up parts of application and that's it. It is not designed to make app more secure, to save developer's time, to increase productivity, even to be hardware independent, and I believe the main reason for its popularity is that it is just the default for Unix. C for Unix is a Visual Basic for Windows. This doesn't make Visual Basic better - this makes C worse.

What about Python? Well, here are some stats.

These are stats from TIOBE (clickable). They don't measure anything - just show some lines that correlate to each other.

It looks like the peak of Python was on February 2011, and since then there was a significant drop. The next peak you see is February 2013 - month before PyCon in California, followed by a deeper decline. Let's see what happened on February 2011:

  • Python 3.2, documentation released on 20 February 2011.
Right. Everybody knew that Python 3.1 is going to be bad, and everybody expected Python 3.2 to be good, but that didn't happen. You may tell people anything - "don't expect", "it is planned", "it is better" - regardless if people hear you or not, they will still have some expectations, and if these expectations don't match the  experience , you see the "disappointment line" decline. You see the second peak didn't bring any good news either.

I am disappointed too, and if you don't want to read yet another boring complain, just skip this paragraph. I expected Python 3 to be ready for the internet age, with cross-platform behavior preferred over system-dependent one, with clear semantics to work with binary data, with non-confusing error handling and API that gives hints and helps to pave your way on uncharted grounds, such as abstract unicode. Maybe Python 3 is beautiful, but I fail to see how - it is not more modular than Python 2 - I can not switch features of the language on and off to taste experimental stuff of propose my own, I don't see any pictures of improved internal structures or . I didn't expect more things to work by default, but I hoped that explicit interfaces continue to be intuitive. There are many little things that sum up and spoil the fun like trailing whitespaces in JSON output that play significant role in providing backward compatibility for Python. I don't know if that is fixed in Python 3, and I don't have any means to track that. When these little things sum up, you realize that you're just wasting time trying to improve things that people don't want to improve. They don't want to improve the process. They don't realize that the problem is not in the language, but in the way they don't want to hear each other. Technology showed that people want to be heard, that they opinion should be  accounted  , not closed as  won't fix  , or  works for me  . It is not a community process, when you rely on abilities of certain individuals to monitor and respond to all traffic and wishes, especially when they fail to do so.

Community process is when there are tools that people can collaborate about, there is research, a place for sharing opinions and sum up the result, a time to track the progress and do the work, and an open environment to experiment and evolve. Where every opinion counts and adds up to become a signal. Where signals are reacted to not because there are people who feel responsible, but because it is fun and has a positive feedback.

There is a certain paralysis. Many people are stuck in corporate against their will, bound by economy. But I am sure in every company it is possible to dedicate a "SyncFriday" - day dedicated to sync with other developers outside to do things in open source with all necessary stuff prepared. If a company can not afford it - why not just leave it. What's the point in helping corporation that doesn't make the world better from your own point of view too?

And much as with corporations, I don't see why anyone should be interested to help Python 3.x to become better. It takes too much energy and is so hopeless, at least for me. Singing papers, writing long explanatory PEP notes, discussing things with your core boss. There are no stats, no summaries, no analysis and comparisons, root cause research - only a lots of text and opinionated and busy individuals like myself.

Can this be changed? Not with text. More people who can draw, animate, make beautiful graphics work to make hard problems visible. This will help. Work with people expectations - if these are unreal - do not try to change them, explain them. Make the problems visible, give people the freedom to try, do not demand, do not press, just create environment, and do not use text - it is useless. 

Art is the future. And the future is both visually appealing, nice to touch and easy to follow.
at No comments:
Labels:

Tuesday, April 29, 2014

Writing SCons Plugin: Discovery

UP201410: Add version info and link to Parts concept.

SCons is a build tool written completely in Python, so that you can just put it into your repository, extend for your own purposes and run directly from checkout without installing anything. SCons documentation doesn't use word plugin to refer to extensions. It calls them Tools. If you're not familiar with SCons concepts, check out this wiki page.

Plugin Discovery


SCons tries its best to avoid magical behavior. That's why it ignores paths and options set in system environment and requires that you specify everything explicitly. The same is true for plugins. Example from SCons man page:
env = Environment(tools = ['default', 'foo'], toolpath = ['tooldir'])
This creates build environment, initializes default tools, sets lookup path for plugins to tooldir/ and enables tool named foo, which is located in tooldir/foo.py. foo.py should have two functions - generate(env) and exists(env).

To test that your tool is found correctly, check env['TOOLS']:
print(env['TOOLS'])
If filename is not there - SCons was unable to find it. If it was a problem with contents of foo.py - SCons would fail with exception.

SCons has an automatic tool discovery mechanism - if you don't like to specify toolpath directly - you may place your tool in one of several locations that SCons scans before executing SConstruct. See description of the --site-dir=dir option for details.

Version compatibility and future


Described behavior is true for SCons 2.3.4 and earlier versions. It may be not very intuitive, so things may change in future, especially if we find resources to integrate Parts.
at No comments:
Labels: , ,

Friday, March 28, 2014

Python C API/ABI compatibility report

UPDATE: There is now an official thread on python-dev.

Upstream Tracker is an open source (GPL) tool that allows to track API/ABI changes between releases of C/C++ libraries. I asked Andrey Ponomarenko, who is the main maintainer of the project, to add Python to the list and here is the result:

http://upstream-tracker.org/versions/python.html

Hope you like it.
at No comments:
Labels: , , , , , ,
Subscribe to: Posts (Atom)