Andrzej Jarzabek wrote:

> On May 18, 5:05 pm, Michal Kleczek <k...@g...com> wrote:
>> Andrzej Jarzabek wrote:
>>
>> >> To tylko potwierdza moja teze - jezeli daje sie w dwa miesiace zrobic
>> >> _uzyteczne_ (w sensie gotowe do wdrozenia produkcyjnego)
>> >> oprogramowanie, to oznacza tylko tyle, ze to oprogramowanie jest po
>> >> prostu trywialne.
>>
>> > Można to też ująć w ten sposób, że prawie zawsze złożone
>> > oprogramowanie ma w sobie "trywialny" ale już użyteczny, choćby w
>> > minimalnym stopniu, rdzeń.
>>
>> Dajmy na to taki RDBMS albo OS - jaki jest ten trywialny ale juz
>> uzyteczny rdzen, ktory daje sie zrobic w dwa miesiace w wersji nadajacej
>> sie do produkcji?
>
> Wziąłeś dwa ogólne przykłady typów programów, które mają od dziesiątek
> lat wielu przedstawicieli gotowych do kupienia lub wzięcia z półki.
> Oczywiście istnieje użyteczny rdzeń RDBMS czy OS jako takiego.
> Przykładowo dla RDBMS będzie to program, który trzyma n tablic, gdzie
> każda tablica ma k kolumn, dane są persistent i istnieje dostęp do
> nich w jakikolwiek sposób, plus jakieś indeksy. Program, który spełnia
> te założenia można napisać nawet w miesiąc i on już może być do czegoś
> użyteczny. Oczywiście tu i teraz, gdzie istnieją gotowe RDBMSy można
> powiedzieć, że skoro mozna mieć znacznie bardziej użyteczne RDBMSy za
> darmo, to użyteczność robionego na zamówienie RDBMSa o takiej
> funkcjonalności jest w praktyce zerowa.

Dokladnie o to mi chodzi - niebanalny system ma taka ceche, ze jego
"fragment" nie ma sensu z punktu widzenia uzytkownika. To nie jest tak, ze
funkcjonalnosc (juz nie mowiac o cechach) daje sie dzielic i "wyciagac" i
nadal twierdzic, ze system jest uzyteczny. To jest IMO mit rozpowszechniany
przez zwolennikow "agile", ktorzy probuja - na szkode klienta - przekonac
go, ze prototyp i produkt to to samo.

>
> Ale w takim razie jeśli pytamy o robienie nowego RDBMSa na zamówienie
> tu i teraz, to powstaje pytanie, dlaczego ktoś w ogóle zamawia nowego
> RDBMSa? Odpowiedź może brzmieć np. tak, że potrzebny jest mu killer
> feature A, którego nie ma żaden dostępny na rynku RDBMS. I w takiej
> sytuacji dla klienta może być nawet użyteczny minimalny RDBMS z killer
> feature A, choćby nie miał języka zapytań,

LOL - to wlasnie jest podstawowa cecha definiujaca RDBMS (specjalnie nie
napisalem DBMS). Sam fakt, ze w pliku mozna przechowywac rekordy stalej
dlugosci nie swiadczy o tym, ze system plikow to RDBMS.

> dostępu przez sieć,
> transakcji, równoległego dostępu,

Mozliwosc rownoleglego dostepu jest jedna z cech definiujacych DBMS (juz nie
mowiac o RDBMS) - za wikipedia:
"A DBMS provides facilities for controlling data access, enforcing data
integrity, managing concurrency control, recovering the database after
failures and restoring it from backup files, as well as maintaining database
security"

[ciach]
>> Niespecjalnie widze roznice (chyba ze "zrobienie release" jest czyms
>> innym niz "wypuszczenie do produkcji" - jezeli tak, to tylko przesuwamy
>> problem).
>
> Release to jest to samo, co wypuścić do produkcji. Gotowy do release
> to nie to samo, co zrobić release. Widzisz już różnicę?

Nie - dla mnie "zrobienie releasa" polega na doprowadzeniu oprogramowania do
stanu "gotowy do release" - czynnosci zwiazane z samym przygotowaniem
artefaktow sa nieistotnymi ( z punktu widzenia procesu tworzenia
oprogramowania ) i w wiekszosci zautomatyzowanymi technikaliami.

--
Michal