Otevírání služby Připravto pro komunitu a API přístup

23.4.2015 11:00 | Přečteno: 1586× | pripravto |

Poslední dobou přemýšlíme, jak správně začít budovat komunitu uživatelů okolo služby Připravto - navrhování a příprava výroby nábytku, tak aby byla vhodná i pro zkušené uživatele a zároveň neodradila začátečníky, případně uživatele, kteří nemají počítač moc v oblibě. Na začátku jsme také udělali chybu asi v tom, že jsme měli hned začít hledat lidi okolo prvotního týmu rychleji. Což si uvědomujeme až teď s odstupem času.

Nyní, když nám služba již začíná pomalu a obstojně fungovat a již máme několik dlouhodobějších uživatelů zjišťujeme, že by bylo vhodné, některé části rozšířit a udělat univerzálnější a více otevřít světu. Tomu se pokouší pomoci poslední článek na Informace o vývoji
Tímto zápiskem představujeme open-source API přístup pro službu v Pythonu, který umožňuje vlastní skriptování služby a hlavně umožní dělat více programovatelné konstrukce, které bez přímého přístupu byly dříve problematické. OCAPI předpokládá uživatelské údaje a pak již jen základní princip služby > tedy vytváření nábytku na základě rozměru, parametrů a následných konstrukčních prvků.
Pro rychlé vyzkoušení je možné použít vlastní nebo demo 'useroc1':'oc1user1piff' účet viz minulé příspěvky. Stáhnout ocapi nainstalovat přes pip a začít používat.

pip install ocapi
#### nebo přes setup.py do virtual env
python setup.py install

Ukázka kódu, která je bez přímého přístupu obtížná, není možné přímo používat vlastní proměnné. Nyní je opravdu jednoduchá a rychlá pro vytvoření. A hlavně následně použitelná i do výroby.

import ocapi.api as oc
import math
args = {'name':'test2','position':[0,0,0],'size':[1000,1000,1000]}
# nastavit uživatele - můžete použít vlastního
# host parameter je ve výchozím nastavení na https://test.pripravto.cz
prod = oc.CabinetMaker(args, username="useroc1", password="oc1user1piff")

Vytvoříme základ a přihlásíme se ke službě začneme postupně přidávat dílce v následných rotacích a velikosti.

for i in range(36):
    size = [18,math.sin(math.radians(i*10))*50+80,18]
    rot = [0,0,10+i*2]
    prod.add_element(pos=[i*20,0,0],size=size,rot=rot)
prod.finish()

#pokud chceme nyní stáhnout ještě obrázek
print(prod.get_image())

Po spuštění tohoto kódu přímo na stránkách můžete zkontrolovat výsledek. Funkce finish() se automaticky pokusí vrátit ucelenou reprezetnaci vytvořeného produktu v JSON formátu, který obsahuje následně informace o dílcích a dalších částech. Pokročilejší ukázkou může být tvorba spodního dílu do kuchyně:

args = {'thickConstr': 18, 'matFront': 'U625', 'frontOut': True,
        'name':'spodni_dil', 'matConstr': '45', 'position': [0, 0, 0],
        'rotation': [0, 0, 0], 'size': [2700, 600, 900]}
prod.parse_args(args)
#vlozime horni desku
prod.add_top(mat='F870', size=38)
#zmensime nasledny prostor
prod.add_diffs(diff=[20, 0, 10, 50, 0, 0])
#vlozime spodni ram pro nohy
prod.add_frame(mat='45',insert_fill=False,low_profile=False, order=[2, 0],width=150,planes=4, diff=[50, 0, 50, 0, 0, 0], thick=18)
#rozdelime prostor
prod.add_dividers(array_dist=[600, 450, 900, 600, 1], part=False)

Nyní již následují další části, které vkládají hlavní konstrukční prvky > vloží korpus do nových prostorů a následně osadí dveře, příčky a pod.

prod.add_basic(area_id=True)
#vlozime police
prod.add_shelve(area_id=4, number=[4, 4, 5])
#rozdelime cast
prod.add_dividers(area_id=3, array_dist=[100, 1], typ='C')
#vlozime zasuvky a dvere do dalsich prostoru
prod.add_doors(area_id=[0, 1, 4],number=1, handleHeight='TOP', handleOrientation='VERTICAL')
prod.add_drawers(area_id=2, number=[1, 1, 150])
prod.add_doors(area_id=3, number=[125, 1], handleOrientation='HORIZONTAL',handleSide='MID', stacking='VERTICAL')
prod.finish()

Po zavolaní finish() se v dané zpracovávané zakázce začne vytvářet nový produkt, který je však pouze je v paměti pouze do doby dokud nepřejdeme na jinou zakázku či ho záměrně neuložíme.
V této době lze přímo přes API z produktu stáhnout obrázek přes funkci get_image()

prod.get_image()

Tohle je v současné době klíčový krok. Přes toto API je možné přímo do služby i ze služby stahovat a odesílat nové informace. Např. je takto možné stáhnout vytvořenou kalkulaci pro daný produkt nebo následně vytvořit optimalizaci a tu opět stáhnout.
Doufáme, že to umožní v budoucnu i tvorbu vlastního rozhraní. Tak to máme i v plánu pro rozhraní Blenderu. Nyní již máme část napojenou, tzn přímo z Blenderu lze přes toto API odeslat data do služby a vytvářet konstrukci, kterou následně služba zpracuje pro výrobní použití.

Co si myslíte o tomto API rozhraní? Bude použitelné? Ideálně ho můžete otestovat a pochlubit se s vlastní konstrukcí. Současná verze by měla být docela dobře použitelná. Při použití IPythonu i Pythonu by se měla k jednotlivým funkcím ukazovat nápověda. Jednotlivé vytvořené konstrukce lze editovat přímo na službě, případně ze služby stáhnout a upravit v API.

Mimo to stále platí, že hledáme schopného vývojáře se znalostí JS a Pythonu:). Naším současným cílem je vylepšit uživatelské rozhraní částečně k úrovni komerčních placených programů.

PS: k ABC, je nějaký důvod, že nelze používat svg obrázky?        

Obrázky

Komentáře

[pavel]

Ahoj, libi se mi to.

Znas X3D, resp X3DOM.js ? Umoznuje to generovat 3D scenu v XML podobne jako vytvaris 2D scenu v SVG/XML.

Tip

[Normotron]

No ve skutečnosti služba generuje celá data ve 3D a následně je pouze vykreslujeme do 2D. Máme výstupy do DXF 2D a 3D, OBJ a BLEND. S tím souvisí i vizualizace. Jinak v současné době se spíše snažíme používat jako formát JSON.

Ale určitě se na to mrknu, neznám to. V minulosti jsme používali ThreeJS. Nyní od toho upouštíme, jelikož to pro naše potřeby zatím neumíme dobře ohnout.

[pavel]

X3D proste pridava jednu dimenzi nad SVG, nic vic, nic min. X3D Hello wolrd

[Marián Kyral]

Ty průhledné obrázky vypadají na tmavém pozadí zajímavě

[Normotron]

Očekával bych že spíše nejsou vůbec vidět. Je škoda, že tam nejde vložit svg, tam se dá změnit dobře pozadí.

[Odin1918]

Pip install ocapi... Neprestavam zasnout, jak divne nazvy maji opensourcove projekty.

[Normotron]

To je jednoduché :) lze si to představit jako oc-api > OptimCabinet-Application Programming Interface. Není v tom žádný složitý systém. Původní program na, kterém je Připravto postavené se jmenuje OptimCabinet :D

Je mi jasné, že by jména mohla být lepší, ale tohle je api, takže jsme to moc neřešili. Máte nějaké vhodné jméno?:)

[Odin1918]

Ona to nebyla kritika. Uprimne ja bych sam lepsi jmeno jiste nevymyslel a muj vytvor by zase prisel divny nekomu jinemu.

[Josef Kufner]

Já bych to nechal delší a nezkracoval tolik. Aspoň by se to lépe hledalo.

[frm]

hned to prvni nejak nefunguje ...

[jan@rixo ~]$ pip install ocapi
-bash: pip: command not found
[jan@rixo ~]$

Pouzivam:

[jan@rixo ~]$ uname -a
Linux rixo 2.6.18-398.el5PAE #1 SMP Tue Sep 16 21:31:44 EDT 2014 i686 i686 i386 GNU/Linux
[jan@rixo ~]$ cat /etc/issue
CentOS release 5.11 (Final)
Kernel \r on an \m

[pavel]

Co zacit treba yumem?

[00000]

Pokud to propojíte s nějakým (velkým v budoucnu) stolařem (výrobcem nábytku), bude to bomba.

Navrhnout a za týden: "Nazdar paní, jdeme Vám montovat tu skříňku, co jste si navrhla...".

Můžete přidat rekonstrukci koupelen.

[Normotron]

Pokud máte na vhodného stolaře kontakt, určitě se sním můžeme spojit. Ono sice tam jde navrhovat takto také, ale spíše je to vhodnější pro profesionála, jelikož si to již dovede hned představit jak to pak bude vhodně vyrábět a může si to uzpůsobit. ;)

Rekonstrukce koupelen - Já tomuto tématu moc nerozumím, takže to je spíše otázka pro někoho kdo se v tom vyzná, jestli by to se současnou platformou šlo. Očekáváme, že za nějakou chvíli bude ve službě možné dělat např. schody a částečně tesařské konstrukce.

[Normotron]

pip je instalační program pro Python. Více viz https://pypi.python.org/pypi/pip

Tzn je to něco jako yum, až na to, že je to určené pro Python. Nejdříve přes yum nainstalujte pip a následně můžete nainstalovat ocapi.

Bohužel pip je v základu dostupný v Pythonu 3.4 a 2.7.9 na ostatních se musí instalovat. Obvykle ale bývá nainstalován. Používá ho mnoho programů pro Python.

[Petr Tomášek]

Kombinovat různé balíčkovací systémy na jednom systému je prasárna. Ale jasně, perl takovou cípovinu má, php taky, tak to musí mít i pýčon...

[Václav "Darm" Novák]

Používám víc verzí ruby a pod nima několik sad gemů různých verzí. Jak by se taková změna běhových prostředí dala optimálně řešit balíčkovacím systémem? U debianu třeba bootstrapem do různých adresářů a chrootem, pravda. Jenže to je oproti rvm dost obludné řešení.

[pavlix]

Jak by se taková změna běhových prostředí dala optimálně řešit balíčkovacím systémem?

Asi úplně stejně jako se řeší tím jiným balíčkovacím systémem, ne? Na Gentoo třeba jenom v ebuildu uvedu, pro které verze Pythonu je balíček určený.

[Normotron]

No jde ještě o to, že pip je multiplatformní funguje jak ve Windows, tak na Mac OS X, takže je vhodné dělat balíčky, tak aby byly dobře dostupné. No a pip se o to docela dobře postará.

Spolu s virtual env je to hodně silný nástroj.

[pavlix]

To už je ovšem úplně jiná story a nevidím v tom osobní přínos, narozdíl od souběžného provozu několika verzí platformy pro daný jazyk.

[Václav "Darm" Novák]

Možná v gentoo, nedovedu si to představit příliš reálně v Archu nebo Debianu, pokud si nechci balit sám.

Podle mě se jedná o výborný způsob distribuce knihoven pro interpretované jazyky. U nich hlídání závislostí na systémových komponentách nemá důvod, důležitá je kontrola závislosti na verzi ruby a mezi jednotlivými knihovnami.

Konkrétně v ruby: Mohu mít několik verzí ruby současně pomocí rvm, zároveň několik různých sad knihoven v jednotlivých verzích. Přepínání běhového prostředí není problém. Moje aplikace v Rails má gemfile se specifikovanou sadou gemů které používá a nasazení kdekoliv se tím neskutečně zjednodušuje. Po synchronizaci s repozitářem nebo zkopírování přes ftp spustím bundle update a vše potřebné se do nového prostředí stáhne. A je mi celkem jedno jestli tam běží gentoo, debian, centos, SLES, nebo Windows, jestli jde o openshift nebo heroku. Zároveň můžu zadat update jen minor verzí knihoven a udržovat celé prostředí aktuální bez možnosti rozbití kompatibility.

Navíc si celkem nedovedu představit jak někdo balí všechny ruby knihovny/programy z rubygems pro všechny distribuce. Třeba v Archu jich je celkem hodně, mnoho jich je v AUR. Zdaleka ne všechny a problém to prostě neřeší. Nebo ano? Jestli lze tohle všechno dělat s balíčkovacími systémy distribucí bez přidělávání si práce tvorbou vlastních balíčků (a ideálně bez závislosti na konkrétní platformě), rád se poučím :)

[pavlix]

Možná v gentoo, nedovedu si to představit příliš reálně v Archu nebo Debianu, pokud si nechci balit sám.

Tohle je spíše věc pythoních distutils, které takhle hezky fungují (až na nepříjemnosti typu sbin). Vytvořit triviálně balíčky pro několik verzí Pythonu pak umí každá distribuce, kde na to někdo tu automatizaci napsal. V zásadě je to jen pár shellovských funkcí. Gentoo má tu výhodu, že si s tím někdo dal tu práci. Nikde jinde jsem to zatím nezkoušel, ale nevyužívá se tam nic, co by bylo pro Gentoo nějak specifické.

V zásadě by nebyl problém ten kód mezi distribucemi sdílet třeba v rámci pythoních distutils. Je potřeba si uvědomit, že je to vcelku triviální automatizace, jen se musí najít někdo, kdo má motivaci ji připravit a především někdo, kdo má motivaci ji nadále udržovat.

Navíc si celkem nedovedu představit jak někdo balí všechny ruby knihovny/programy z rubygems pro všechny distribuce.

V dobře udělané distribuci spočívá příprava balíků v sepsání několika řádků metadat. Jestliže ta metadata už někde na serveru pohromadě jsou, v zásadě by nebyl problém, kdyby tím někým, kdo balí všechny knihovny/programy byl vcelku jednoduchý skript. Výsledek by byl stejně nekvalitní, jako když ten server používáš přímo, ale v dalším kroku by nad tím bylo možné udělat nějakou stabilizaci verzí jako přidanou hodnotu.

Zdaleka ne všechny a problém to prostě neřeší. Nebo ano?

Jistěže ano, podstata je v tom, že zabalit takovou knihovnu by nemělo být složitější než ji nainstalovat. V extrémním případě by bylo možné řešit to pluginem do systémového balíčkovače a balíčkování by odpadlo úplně a řešila by se následná úprava metadat. Konec konců by se stejný princip dal aplikovat i na céčkovské projekty, pokud by používali nějakou malou množinu dobře detekovatelných a ovladatelných build systémů, alespoň tedy pro projekty, které fungují dobře ve výchozí konfiguraci.

[Václav "Darm" Novák]

OK… Tohle by řešením bylo. Ještě nějak umožnit instalovat balíčky pod lokálním uživatelem do jeho vlastního prostředí a prosadit standard pro všechny distribuce. A nebo použít už existující standardizované řešení, které funguje všude :) Já nevím, stále mi připadá stávající řešení lepší.

[pavlix]

Ještě nějak umožnit instalovat balíčky pod lokálním uživatelem do jeho vlastního prostředí

Na úrovni lokálního uživatele si zatím vystačím s těmi nástroji specifickými třeba pro Python. Lokálních balíků mívám málo a když se to nějak pokazí, tak mě nebolí si najít ten adresář, promazat ho a naházet tam jenom to, co potřebuju. Teoreticky by to šlo i na úrovni systému, ale tam je prostě problém ten, že cokoli tam nainstaluješ, tak se ti může nějak vymstít.

a prosadit standard pro všechny distribuce.

To zní hrozně vznešeně a složitě, přito by stačilo standardizovat jenom pár drobností a klidně by se to mohlo týkat jenom určité třídy software. Třeba v případě Pythonu už je do značné míry standardizováno, i když je samozřejmě, co zlepšovat.

Já nevím, stále mi připadá stávající řešení lepší.

Já osobně nevidím vůbec prostor pro srovnání, nebavíme se o konkurenčních technologiích, ale o jednotlivých dílech skládačky. Ani to Gentoo nevnímám jako distribuci, na kterou by měli všichni přejít, ale spíš jako skupinu lidí, která vyrobila některé dílky skládačky o kterých si jiní zatím můžou nechat jenom zdát.

[Václav "Darm" Novák]

Možná ty… Pokud jde například o mnou zmíněný openshift, heroku nebo jiné podobné cloudové služby, rubygems, pip a podobné jsou asi nejschůdnější řešení.

[Normotron]

Ano také to tak vidím, jde o to, že pip je docela dobře přístuný, Neříkám, že je dokonalý, má hodně svých chyb, třeba vyžaduje určitou strukturu projektu, dále nutnost zapisovat většinu souborů do setup a tak podobně a pro větší projekty, již nemusí stačit. Avšak pro menší je rychlý a efektivní.

[pavlix]

Asi si nerozumíme.

[Dvojité Wéčko]

Kdybys neměl na své pracovní stanici roota, byl bys za tyto prasárny velmi vděčný.

[Normotron]

pokud nemůžete použít PIP, ale máte Python a setup tools, tak možná bude pro Vás jednodušší zkusit variantu přímo přes.

wget https://bitbucket.org/pripravto/ocapi/get/default.tar.gz
tar -xvf default.tar.gz
cd pripravto....

nainstalovat přes setup

python setup.py install

Nebo jen rozbalit a na importovat přes Python.

$ python

>>> import ocapi.api as api

[Petr Tomášek]

A nebylo by jednodušší zabalit to do do DEB/RPM/... a slušně to nainstalovat?

[Bystroushaak]

Ne, nebylo, bylo by to podstatně složitější, nehledě na závislosti, které skoro určitě v DEB/RPM nebudou a spravovat je a dostávat do distribuce je práce pro masochistu.

PIP je standard pro distribuci python balíčků a jako takový v DEB/RPM je, tak nevidím problém v jeho instalaci. Někdy to jde i přes easy_install: sudo easy_install pip.

[pavel]

proc ne rovnou easy_install ocapi ?

[Bystroushaak]

Měli by jste si přidat i nějaké to description do setup.py.

$ pip search ocapi
ocapi                     - UNKNOWN

[Normotron]

Jo, děkuji za připomenutí, omylem jsem ho před tím vymazal.

[Bystroushaak]

Pripravto api connect to OptimCabinet service mi přijde takový dost zmatený a asi bych vůbec nepochopil, co že to má být.