Short of Inventory aka. inwentarz

Software
1

Myślę, że pora opisać projekt który stopniowo ewoluuje, za pięknie opisanymi szufladkami z komponentami.

Skrótem od Inwentarza jest “I” i pod tą jedno literową subdomeną stoi //i.hsp.sh

Jest to kolejny krok w ewolucji inwentaryzacji, która odbywa się równolegle z inwestycjami w szufladki oraz katalogowania tego co już mamy. Którego liderami są @mamert i @hamsterking.

Ja zgodnie z deklaracją zająłem się przygotowaniem rozwiązaniem do generowania naklejek na powstające szufladki. Na początku powstał okropny skrypt szufladki.py. Skrypt miał jedną ciekawą własność, ponieważ zrzucał do bazy danych wszystkie naklejki które drukował. Obserwacje poczynione wokół generacji naklejek posłużyły do stworzenia labello. Dzięki temu, już nikt nie musi taplać się w ręcznym odpalaniu mojego Pythonowego sztynksu przy drukowaniu etykiet.

Z kolei baza danych która była przy okazji generowana, posłużyła do stworzenia indeksu. A następnie stworzenia naklejek z kodem QR które odwołują się do rzeczonego indeksu. Polecam zeskanować QR kody na szufladkach, a tutaj przykład tego co jest w bazie: //i.hsp.sh/0076

Wizja

Obecnie programik jest bardzo spartański. Oczywiście istnieją rozwiązania które w bardziej kompleksowy sposób rozwiązują problem katalogowania części. Ale może niekoniecznie chciałem rozwiązać dokładnie ten problem.

To co chciałbym aby Short of Inventory robiło, to śledzenie przypływu rzeczy, ich lokalizacja, i odnośniki do dodatkowych informacji.

To czego nie chcę robić to przechowywać dodatkowych informacji, albo drukować etykiet do ich śledzenia. Jestem przekonany, że tę rolę wypełniają inne narzędzia: wiki, labello.

Moją wizją są serwisy które są w stanie między sobą się integrować i uwydatniać swoje mocne strony.
Short of Inventory powinno zajmować się czasem, miejscem i własnością rzeczy. Wszystkie inne dodatkowe rzeczy powinny być zaciągane z zewnątrz.

Implementacja

Na razie myślałem aby zastosować event sourcing, ale ponieważ nie jest to trywialne, to trochę zwlekam. Wierzę, że rozwiąże to sporo problemów w przyszłości w temacie umiejscowienia w czasie indeksowanych przedmiotów.

Zamierzam silnie korzystać z tego co oferuje WWW, czyli hiperłącz do innych serwisów. Już teraz można dodawać generyczne generowanie odnośników dla pojedynczych komponentów w szufladkach. (Np. kliknij na odnośnik “wiki” na //i.hsp.sh/0076). Drukowanie etykiet działa identycznie. Tworzenie adapterów do innych źródeł danych powinno być w miarę proste.

Kończąc, projekt jest we wczesnych fazach rozwoju. I pewnie będzie ewoluować podczas licznych rozmów w HS. Jestem też chętny na dyskusję tutaj. Jak również na pomoc i współpracę.

2 polubienia
2

Wobec wczorajszych dyskusji które lepiej nakreśliły problemy tego rozwiązania i jego granic. Okazuje się, że stworzenie czegoś bardzo generycznego jest niebywale trudne i ciężko nakreślić gdzie się kończy inwentarz, a gdzie jakieś inne informacje. Dyskusja była wobec systemu książek, który możliwe, że rządzi się innymi prawami.

W najbliższych tygodniach skupiłbym się na dobrej implementacji zarządzania zużywalnymi komponentami, śledzenia ich ilości, i ogólnie ich zarządzania. Zwłaszcza przy użyciu event sourcing’u.

Czy powinno się wciągać inne rzeczy do tego systemu? Czy każdy fizyczny przedmiot powinien być wbity do systemu? Co jest warte śledzenia w ten sposób? A kiedy coś warto wyrzucić do innego katalogu?

Inne ważne problemy, to odkrywalność i użyteczność systemu. Niestety jako twórca mam ograniczony wgląd w ten aspekt. Okazuje się, że w naszej kulturze QR kody nie są oczywistością. Nawigacja w samym systemie też może być w jakiś sposób trudna. Czy da się zachować prostotę przy zachowaniu możliwości? Te rzeczy wyjdą gdy więcej osób zacznie z tego korzystać. A żeby tak się stało, to system musi stać.

3

Bardzo fajnie wyszło :slight_smile:

Sądzę że dobrze by mieć BARDZO zwięzłą instrukcję w 3 kopiach, jedna zawieszona na ściance szufladek.
Wtedy jakoś wyjdzie sam może jakiś pattern używania.

Czy można listować / szukać stworzone labele?

2 polubienia
4

hmmm

Czy to czysta architektura @psuwala?

1 polubienie
5

Jaka cebula :joy:

Teraz jeszcze trzeba zdefiniować Entities (a tak serio to agregaty), Eventy, Commandsy i resztę rzeczy, która określa co płynie między tymi komponentami.
Do tego polecam event storming :3.

Jest już event sourcing adapter zrobiony?

6

Wymagania do inventory

Wymagania do systemu inventory

Strona wejściowa

SOI-0001

https://i.hsp.sh/ powinna być czymś konkretnym

  • Strona z instrukcją
  • entry pointem do wyszukiwarki

Wymagania ogólne

SOI-0002

Definicja obiektu:

Obiektem w bazie komponentów jest pojedynczy wpis dotyczący danego typu komponentu. Więcej w SOI-0301

SOI-0003

Każdy obiekt to osobny wpis w bazie, reprezentowany osobnym numerem identyfikacyjnym.

SOI-0004

Każdy typ elementu (obiekt) ma swoją fizyczną lokalizację. W danej lokalizacji może znajdować się wiele typów komponentów.

Np.:

  • szufladki są podzielne na trzy. Każda komora szufladki zawiera pojedynczy typ komponentu
  • organizery są jeszcze bardziej podzielne. Każda komora to miejsce na osobny typ komponentu, jeśli dany komponent nie jest łatwo rozróżnialny, jest identyfikowany poprzez pozycję w organizerze
  • W większej kuwecie może się znajdować wiele różnych obiektów. Jeśli są łatwo rozróżnialne, nie potrzeba ich dodatkowo opisywać - np moduły w kuwecie z modułami

Przeglądarka komponentów

SOI-0101

System powinien pozwalać na przeglądanie i wyszukiwanie komponentów

SOI-0102

Przeglądanie według kategorii. Widok powinien pokazywać listę komponentów w danej kategorii, z podglądem kluczowych parametrów.

SOI-0103

Sortowanie względem parametrów, we widoku listy, byłoby ekstra funkcjonalnością.

SOI-0104

System powinien umożliwiać wyszukiwanie komponentów względem:

  • kategorii
  • wszystkich dostępnych parametrów/atrybutów

Kategorie

SOI-0201

Elementy powinny być porządkowane wg kategorii

SOI-0202

Drzewo kategorii może rozrastać się dynamicznie:

  • Można dodawać nowe kategorie/podkategorie
  • można przenosić elementy pomiędzy kategoriami
  • można zmieniać nazwę lub parametry kategorii
  • można usuwać puste kategorie (takie które nie mają żadnych ddzieci)

SOI-0203

Każdy węzeł kategorii może mieć krótki opis (np żeby wyjaśnić co się znajduje w danej kategorii)

SOI-0204

Elementy nie powinny znajdować się węzłach które zawierają inne podkategorie. Jeśli nie ma dedykowanej podkategorii, to ostatnim węzłem kategorii zawsze powinna być podkategoria “Ogólne”, “Różne” lub “Inne” - zależy od kontekstu

SOI-0205

Propozycja podstawowych kategorii:

  1. Półprzewodniki
    1. Diody
      1. Uniwersalne
      2. Schottky
      3. Zenera
      4. TVS
      5. moduły
    2. Mostki prostownicze
    3. Tyrystory/Triaki
    4. Tranzystory
      1. MOSFET
      2. BJT
    5. Ukłądy scalone
      1. Logiczne
      2. Analogowe i mieszane
      3. Mikroprocesory/Mikrokontrolery
      4. Pamięci
      5. Regulatory napięcia
        1. Liniowe
        2. Przetwornice
  2. Moduły
  3. Optoelektronika
    1. Wyświetlacze
    2. LED
      1. THT
      2. SMD
    3. LED mocy
    4. Transoptory
    5. Lasery
    6. Foto czujniki
  4. Elementy pasywne
    1. Rezystory
      1. THT
      2. SMD
    2. Potencjometry
    3. Kondensatory
      1. MLCC SMD
      2. Ceramiczne THT
      3. Elektrolityczne SMD
      4. Elektrolityczne THT
      5. Tantalowe
      6. Superkondensatory
    4. Kwarce i filtry
      1. Rezonatory
      2. Generatory kwarcowe
    5. Dławiki
      1. Ogólne
      2. Dławiki Mocy SMD
      3. Dławiki Mocy THT
    6. Anteny
    7. Warystory
  5. Złącza
    1. Sygnałowe
      • Opis: w tym kołkowe o różnych rastrach
    2. Do przesyłu danych
      • Opis: W tym D-SUB, USB, RJ-45)
    3. Złącza koncentryczne / RF
      • Opis: BNC, SMA, SMB, SMC, F
    4. Zasilające
      • Opis: AC 230V, Barrel Jack
    5. Audio
      1. Jack
      2. Różne
    6. Konektory i końcówki kablowe
  6. Bezpieczniki
  7. Przełączniki
    1. TACT
      • Opis: Tj. Push buttons
    2. Dip-switch
    3. Suwakowe
    4. Dźwigniowe
    5. Przyciskane
    6. Klawiatury
    7. Zadajniki kodu
  8. Przekaźniki
  9. Transformatory i rdzenie
    1. Rdzenie Ferrytowe
  10. wentylatory i chłodzenie
  11. przewody i kable
  12. Elementy mechaniczne
    1. Śruby
    2. Wkręty
    3. Nakrętki
    4. Podkładki
    5. Nity
    6. Elementy dystansowe
    7. Dopisać rzeczy do które mamy w spejsie, np dotyczące mechaniki do drukarek
  13. obudowy

Obiekty w bazie

SOI-0301

Każdy obiekt powinien mieć możliwość posiadania wielu atrybutów/parametrów

SOI-0302

Parametry fizyczne są definiowane liczbami z użyciem przedroków SI oraz z użyciem jednostek SI
Np.
100uF
2,7nF
33pF
27mA
220uH
1,5uH
0,2Ohm
1kOhm
274kOhm

SOI-0303

Przykładowe zestawienie parametrów dla różnych typów komponentów:

  1. Wszystkie typy komponentów

    1. Nazwa
    2. MPN (Manufacturer Part Number) - opcjonalnie
    3. Opis
    4. Typ obudowy
    5. Typ montażu (SMD/THT)
    6. Link do datasheeta

  2. Diody

    1. Uniwersalne/Schottky
      1. Napięcie wsteczne maks (V_{RRM})
      2. Prąd przewodzenia maks (I_F)
      3. Napięcie przewodzenia maks. (V_F)
    2. Zenera
      1. Napięcie Zenera (V_Z)
      2. Moc rozpraszana
      3. Tolerancja %
    3. TVS
      1. Struktura: jednokierunkowa/dwukierunkowa
      2. Moc rozpraszana (P_{PPM})
      3. Napięcie przebicia (V_{BR})

  3. Tranzystory

    1. Tranzystory MOSFET
      1. Typ tranzystora (N-MOSFET/P-MOSFET/etc)
      2. Napięcie dren-źródło (V_{DSS})
      3. Prąd drenu (I_D)
      4. Moc rozpraszana (P_D)
    2. BJT
      1. Typ tranzystora (NPN/PNP/etc.)
      2. Napięcie kolektor-emiter (V_{CEO})
      3. Prąd kolektora (I_C)
      4. Moc rozpraszana (P_D)

  4. Układy spalone (IC)

    1. IC Logiczne
      • Możliwe różne wartości
    2. Analogowe i mieszane
      • Możliwe różne wartości
    3. Mikroprocesory/Mikrokontrolery
      1. Producent
      2. Rodzina (np. AVR/STM32)
      3. Pamięć programu
      4. Pojemność pamięci SRAM
    4. Pamięci
      1. Typ pamięci
      2. Pojemność
    5. Regulatory napięcia
      • Możliwe różne wartości

  5. Optoelektronika

    1. Wyświetlacze
      1. Typ (np. Alfanumeryczne/LED/TFT)
    2. LED
      • TBD
    3. LED mocy
      1. Moc
      2. Napięcie przewodzenia (I_F)
    4. Inne
      • TBD

  6. Elementy pasywne

    1. Rezystory
      1. Rezystancja (R)
      2. Moc rozpraszana (P_D)
    2. Potencjometry
      1. Rezystancja (R)
      2. TBD
    3. Kondensatory
      1. Ceramiczne
        1. Pojemność (C)
        2. Napięcie pracy
        3. Dielektryk (np. X7R, C0G)
      2. Elektrolityczne/Tantalowe
        1. Pojemność
        2. Napięcie pracy
    4. Kwarce i filtry
      1. Rezonatory
        1. Częstotliwość
      2. Generatory kwarcowe
        1. Częstotliwość
        2. Napięcie zasilania
    5. Dławiki (wszystkie)
      1. Indukcyjność (L)
      2. Prąd pracy
    6. Anteny
      1. TBD
    7. Warystory
      1. Napięcie warystora

  7. Złącza

    1. Sygnałowe
      1. Raster
      2. Ilość pinów
      3. Ilość rzędów
    2. Inne
      1. TBD

  8. Bezpieczniki

    1. Typ
    2. Prąd bezpiecznika
    3. napięcie

  9. Przełączniki

    1. Typ (np. SPST-NO/DPDT/etc)
    2. Ilość wszystkich pozycji
    3. Ilość styków
      pozostałe TBD
5 polubień
7

Elo, nie wiem czy przerabiacie istniejący system czy piszecie od zera ale pomyślałem że podrzucę - ja w HSŁ zaproponowałem gnujdb: https://github.com/hakierspejs/gnujdb

Ficzerów jest bardzo mało, całość jest raczej jako PoC systemu do inwentaryzacji spejsowych rzeczy.

Wystawione tutaj: https://g.hs-ldz.pl

8

To ja ci powiem, że oba nasze systemy są na podobnym poziomie. Ale mam szczerą nadzieję, że to co u nas powstanie zastąpi gnujdb :wink:
Ogólnie zapraszam do współpracy, jeśli są u was zainteresowani koderzy.

Po pierwsze, odseparowałbym tworzenie QR kodów z kompetencji tego systemu. Wydaje mi się sensowniejsze generowanie jakiejś struktury która mogłaby by być przetworzona przez inny serwis: Labello - web service do etykieciarki albo https://github.com/jimevins/glabels-qt.

9

Hej, na podstawie wymagań @radian (bardzo ładne wymagania, ale słabo się formatują tutaj), zrobiłem prosty Use Case Diagram wg. standardu ULM. Dodałem od siebie casey “Dodanie elementu”.
Wymagania funkcjonalności dodania elementu:
SOI-0401: System powinien umożliwiać dodanie elementów do bazy.
SOI-0402: System nie powinien umożliwiać dodanie elementów o tej samej nazwie do bazy.
SOI-0403: System, podczas dodawanie elementu, powinien wymagać wypełnienia pól atrybutów opisanych w SOI-0303, w zależności od kategorii.
SOI-0404: System nie powinien umożliwiać dodania elementu, który ma jeden lub więcej puste pole atrybutu
SOI-0405: System nie powinien umożliwiać dodania znaków, które są zdefiniowane jako nieakceptowalne
Notka:Chodzi mi tutaj o każde znaki, które mogą służyć do wstrzyknięcia zapytania do bazy danych, ale nie znam technologi jaka tutaj jest używana
SOI-0406: Jeśli użytkownik dodane komponent, który nie spełnia wymagań SOI-0402,SOI-0404 i SOI-0405, wtedy System powinien zwrócić informacje o błędzie i nie dodać elementu do bazy.

Mój pierwszy use case poniżej:

obraz
obraz840×440 19.1 KB

Całość trochę ma błędów związanych ze stylem czy zasadami, ale mam nadzieje, że dość przejrzyste.

10

W kwestii wymagania SOI-02##, czyli kategorii.

Czym jest kategoria? Czym jest szufladka? Czy kategoria nie jest jakąś abstrakcyjną szufladką? Jeśli kategorie mają swoje subkategorie, a szufladki mają swoje przedziałki w środku. To czym się właściwie różnią? Jeśli przechowują te same rzeczy, ale jakby w innych miejscach? I czy kategoria sama w sobie nie może być szufladką? Mamy już chociażby szufladki które przechowują jedną kategorię rzeczy. Mamy kategorie które zajmują wiele szufladek.

Chyba wrzucę to na #filozofia

2 polubienia
11

Weszła aktualizacja

image
image792×446 22.8 KB