Szukam webmastera [polish only]

Ostatnio pisałem o moim pierwszym, malutkim, projekciku w Pythonie – kanasta.depesz.com.

Całość działa, ale – mimo, że nie spodziewam się mieć tam użytkowników (tzn. innych niż nasza czwórka), chciałbym by to wyglądało, i może było odrobinę prostsze w użyciu.

Szukam więc webmastera. Czego oczekuję? Rzeczony webmaster …

  • pobierze sobie z githuba soft, postawi go u siebie (do celów testowych, ja mam gdzie hostować) – potrzebne – postgres, python, flask, psycopg2, matplotlib. W razie gdyby się okazało, że to olbrzymi problem – dogadamy się.
  • w oparciu o to co widzi, zaproponuje wygląd (jpgi z wyglądem)
  • wymieni ze mną kilka(naście) maili nt. propozycji wyglądu i moich “przemyśleń"
  • przekonwertuje jpg'i do postaci szablonów jinja2, cssów, js'ów
  • doda logikę w js'ach do walidacji i automatyzacji pewnych operacji (głównie rejestracja nowych partii)
  • dostarczy zmiany w dowolny sposób (pull request, mail, gołąb pocztowy)
  • wystawi na całość fakturę

Chętna/chętny? Napisz. Aby móc wybrać potrzebowałbym tylko wstępnej wyceny (koszt i czas). Przesłanie obrazka z wstępną wizualizacją bardzo pomoże.

Nie wiem ile jestem w stanie zapłacić. Tzn. nie wiem ile takie coś może kosztować, a nie chcę zastrzegać, że zapłacę “x" bo może się okazać, że moje “x" jest np. o dwa rzędy wielkości za wysokie jak na taki mały projekcik.

Praca nie jest “na tempo, bo jutro użytkownicy na to wchodzą". To jest małe, spokojne, luźne zleconko które pewnie można zrobić w godzinę.

Request for help with Python/Flask – Prośba o pomoc z Pythonem/Flaskiem

( wersja polska poniżej )

I (not-so) recently started to learn Python. To have some playground that I can work on, I decided to write simple website that will let me track scores of a card game that I play with my family – Canasta.

To write it, I chose to use Flask framework, so I learned at the same time both Python and Flask.

Final result (without layout, just functionality) is on github.

If any of you does write Python and/or Flask, I would greatly appreciate all comments. Even the harsh ones. If anything is wrong, or simply not really good – let me know – I'm treating it as a way to learn so all feedback would be good.

Just a word of warning – if you'll decide to look at it – you will be dealing with very bad Python code. Brace yourself.

Niedawno zacząłem uczyć się Pythona. Uczę się najlepiej robiąc coś, więc stwierdziłem, że zrobię prosty site do śledzenia wyników gry w którą gram z rodziną – kanasty.

Zdecydowałem, że użyję Flask'a – dzięki czemu uczyłem się jednocześnie i języka (Python) i frameworka (Flask).

Działająca wersja (bez wyglądu, sama funkcjonalność!) jest na githubie.

Jeśli znasz Pythona i/lub Flaska, byłbym bardzo wdzięczny za przejrzenie tego kodu i skomentowanie. Nawet zbluzganie. Jeśli cokolwiek jest źle, lub nie-za-dobrze, daj mi znać. To (ten soft) to dla mnie metoda na nauczenie się, więc każdy komentarz jest mile widziany.

Słówko ostrzeżenia jedynie: jeśli się zdecydujesz na to spojrzeć, miej świadomość, że to będzie bardzo zły kod w Pythonie. Tragiczny. Bądź gotów.

Waiting for 9.2 – pg_stat_statements improvements

Three interesting patches:

  • On 27th of March, Robert Haas committed patch: 
    New GUC, track_iotiming, to track I/O timings.
 
Currently, the only way to see the numbers this gathers is via
EXPLAIN (ANALYZE, BUFFERS), but the plan is to add visibility through
the stats collector and pg_stat_statements in subsequent patches.
 
Ants Aasma, reviewed by Greg Smith, with some further changes by me.
  • On 27th of March, Robert Haas committed patch: 
    Expose track_iotiming information via pg_stat_statements.
 
Ants Aasma, reviewed by Greg Smith, with very minor tweaks by me.
  • On 29th of March, Tom Lane committed patch:

    Improve contrib/pg_stat_statements to lump "similar" queries together.
 
pg_stat_statements now hashes selected fields of the analyzed parse tree
to assign a "fingerprint" to each query, and groups all queries with the
same fingerprint into a single entry in the pg_stat_statements view.
In practice it is expected that queries with the same fingerprint will be
equivalent except for values of literal constants.  To make the display
more useful, such constants are replaced by "?" in the displayed query
strings.
 
This mechanism currently supports only optimizable queries (SELECT,
INSERT, UPDATE, DELETE).  Utility commands are still matched on the
basis of their literal query strings.
 
There remain some open questions about how to deal with utility statements
that contain optimizable queries (such as EXPLAIN and SELECT INTO) and how
to deal with expiring speculative hashtable entries that are made to save
the normalized form of a query string.  However, fixing these issues should
require only localized changes, and since there are other open patches
involving contrib/pg_stat_statements, it seems best to go ahead and commit
what we've got.
 
Peter Geoghegan, reviewed by Daniel Farina

Continue reading Waiting for 9.2 – pg_stat_statements improvements

Waiting for 9.2 – More rewrite-less ALTER TABLE ALTER TYPEs

Three patches for you today, all committed by Robert Hass:

  • On 7th of February, patch: 
    Add a transform function for numeric typmod coercisions.
 
This enables ALTER TABLE to skip table and index rebuilds when a column
is changed to an unconstrained numeric, or when the scale is unchanged
and the precision does not decrease.
 
Noah Misch, with a few stylistic changes and a fix for an OID
collision by me.
  • also on 7th, patch: 
    Add a transform function for varbit typmod coercisions.
 
This enables ALTER TABLE to skip table and index rebuilds when the
new type is unconstraint varbit, or when the allowable number of bits
is not decreasing.
 
Noah Misch, with review and a fix for an OID collision by me.
  • and a day later final patch: 
    Add transform functions for various temporal typmod coercisions.
 
This enables ALTER TABLE to skip table and index rebuilds in some cases.
 
Noah Misch, with trivial changes by me.

Continue reading Waiting for 9.2 – More rewrite-less ALTER TABLE ALTER TYPEs

Waiting for 9.2 – EXPLAIN TIMING

On 7th of February, Robert Haas committed patch:

Sometimes it may be useful to get actual row counts out of EXPLAIN
(ANALYZE) without paying the cost of timing every node entry/exit.
With this patch, you can say EXPLAIN (ANALYZE, TIMING OFF) to get that.
 
Tomas Vondra, reviewed by Eric Theise, with minor doc changes by me.

Continue reading Waiting for 9.2 – EXPLAIN TIMING

Waiting for 9.2 – JSON

On 31st of January, Robert Haas committed patch:

Like the XML data type, we simply store JSON data as text, after checking
that it is valid.  More complex operations such as canonicalization and
comparison may come later, but this is enough for not.
 
There are a few open issues here, such as whether we should attempt to
detect UTF-8 surrogate pairs represented as \uXXXX\uYYYY, but this gets
the basic framework in place.

and then, 3 days later, Andrew Dunstan committed another one, related:

Also move the escape_json function from explain.c to json.c where it
seems to belong.
 
Andrew Dunstan, Reviewd by Abhijit Menon-Sen.

Continue reading Waiting for 9.2 – JSON

Waiting for 9.2 – temporary file stats per database

On 26th of January, Magnus Hagander committed patch:

Add counters for number and size of temporary files used
for spill-to-disk queries for each database to the
pg_stat_database view.
 
Tomas Vondra, review by Magnus Hagander

Continue reading Waiting for 9.2 – temporary file stats per database