On 2013-01-18, PK <P...@n...com> wrote:
> On 2013-01-18, Roman W <b...@g...pl> wrote:
>> Jak ktos chce o 17.00 aplikację na jutro, to sam sie prosi o kłopoty.
>
> Realia. Ten ktoś nie chce świetnej aplikacji, nie chce działa sztuki,
> nie chce najefektywniejszych algorytmów. Chce mieć konkretne narzędzie
> robiące konkretną rzecz w konkretnym czasie. Bardzo możliwe, że tylko
> raz, a potem "del" i kolejny projekt.

Taką robotę zleca się klepaczowi kodu, a nie sysadminowi. Nawet jeśli
ten sysadmin ma przygotowanie programistyczne. Takie są realia.

--
Secunia non olet.
Stanislaw Klekot

do góry

On 2013-01-12, darekm <d...@e...com> wrote:
>
>> Proszę bardzo, jedziesz. Ja w Perlu robię tak:
>> #v+
>> $logger->warn(msg "coś się zepsuło",
>> file => $filename, errorcode => $?, warning => $msg);
>> #v-
>>
>> Masz obiekt loggera z metodą do wysyłania ostrzeżeń. Potrzebujesz podać:
>> 1) własny komunikat
>> 2) nazwę pliku, którego np. otwarcie sprawiło problem
>> 3) kod błędu (errno lub analogiczny)
>> 4) treść komunikatu od systemu
>> Uwagi:
>> * 4) może zawierać cokolwiek i nie masz nad tym kontroli
>> * wpis w logu ma być czytelny dla człowieka i maszyny
>> * masz w kodzie móc dodać kolejne pola ad-hoc, bez edycji w innych
>> plikach czy miejscach bieżącego pliku
>>
>
> Nie ma większego problemu, jest kilka metod na rozwiązanie w zależności
> od potrzeb. Może to boś ściśle typowane lub nie (variant, string). Czas
> życia komunikatu zarządzany ręcznie (obiekty) lub automatycznie
> (interface, open string, array of). Możesz mieć przeładowaną funkcję warn.
>
>
> stringi są w Delphi automatycznie zarządzane i efektywnie
> przekazywane. Podobnie dynamiczne tablice stringów. Parsowanie jest
> trywialne. Mam zbór funkcji które zbudują taki komunikat (tablica
> asocjacyjna) jak wskazałeś a sam logger w pełni asynchroniczny.

Oczywiście. Drzewa zasłaniają ci las.

Nie interesuje mnie czas życia tego stringa. Nie interesuje mnie
przeciążanie funkcji warn, zwłaszcza że ona powinna być biblioteczna.
To, co mnie interesuje, to definiowanie pól w komunikacie ad-hoc,
w miejscu, w którym tworzę komunikat. *Bez przygotowań*, w tym bez
deklarowania dodatkowych zmiennych tylko na potrzeby logowania.

--
Secunia non olet.
Stanislaw Klekot

do góry

Dnia Mon, 21 Jan 2013 22:34:41 +0000 (UTC), Stachu 'Dozzie' K. napisał(a):

>>> Proszę bardzo, jedziesz. Ja w Perlu robię tak:
>>> #v+
>>> $logger->warn(msg "coś się zepsuło",
>>> file => $filename, errorcode => $?, warning => $msg);
>>> #v-
> Nie interesuje mnie czas życia tego stringa. Nie interesuje mnie
> przeciążanie funkcji warn, zwłaszcza że ona powinna być biblioteczna.
> To, co mnie interesuje, to definiowanie pól w komunikacie ad-hoc,
> w miejscu, w którym tworzę komunikat. *Bez przygotowań*, w tym bez
> deklarowania dodatkowych zmiennych tylko na potrzeby logowania.

Nie znam Perla i nie wiem jak dokladnie interpretowac Twoj przyklad w nim
podany, ale Delphi wspiera closure:

http://interactiveasp.net/blogs/spgilmore/archive/20
10/06/17/anonymous-methods-and-closures-in-delphi-20
10.aspx

--
pozdro
R.e.m.e.K

do góry

On 2013-01-22, R.e.m.e.K <g...@d...null> wrote:
> Dnia Mon, 21 Jan 2013 22:34:41 +0000 (UTC), Stachu 'Dozzie' K. napisał(a):
>
>>>> Proszę bardzo, jedziesz. Ja w Perlu robię tak:
>>>> #v+
>>>> $logger->warn(msg "coś się zepsuło",
>>>> file => $filename, errorcode => $?, warning => $msg);
>>>> #v-
>> Nie interesuje mnie czas życia tego stringa. Nie interesuje mnie
>> przeciążanie funkcji warn, zwłaszcza że ona powinna być biblioteczna.
>> To, co mnie interesuje, to definiowanie pól w komunikacie ad-hoc,
>> w miejscu, w którym tworzę komunikat. *Bez przygotowań*, w tym bez
>> deklarowania dodatkowych zmiennych tylko na potrzeby logowania.
>
> Nie znam Perla i nie wiem jak dokladnie interpretowac Twoj przyklad w nim
> podany, ale Delphi wspiera closure:
>
> http://interactiveasp.net/blogs/spgilmore/archive/20
10/06/17/anonymous-methods-and-closures-in-delphi-20
10.aspx

Fajnie, ale gdzie ja mówiłem o domknięciach? Nie odniosłeś się *w ogóle*
do tego, co napisałem: chcę funkcję logującą, której mogę podać pola
(pary nazwa-wartość) w dowolny sposób w danym momencie mi potrzebny
i której mogę te pola podać bez dodatkowych przygotowań, w jednym
wyrażeniu będącym wywołaniem funkcji logującej.

Nawiasem mówiąc, dobrze świadczy o Delphi fakt, że funkcje anonimowe
i domknięcia zostały dodane raptem dwa lata temu. Reszta świata ma to
powszechnie od lat parunastu, dziękuję bardzo. Ale to takie moje
marudzenie o języku, za którym nie przepadam.

--
Secunia non olet.
Stanislaw Klekot

do góry

W dniu 2013-01-21 23:34, Stachu 'Dozzie' K. pisze:
> On 2013-01-12, darekm <d...@e...com> wrote:
>>
>>> Proszę bardzo, jedziesz. Ja w Perlu robię tak:
>>> #v+
>>> $logger->warn(msg "coś się zepsuło",
>>> file => $filename, errorcode => $?, warning => $msg);
>>> #v-
>>>
>>> Masz obiekt loggera z metodą do wysyłania ostrzeżeń. Potrzebujesz podać:
>>> 1) własny komunikat
>>> 2) nazwę pliku, którego np. otwarcie sprawiło problem
>>> 3) kod błędu (errno lub analogiczny)
>>> 4) treść komunikatu od systemu
>>> Uwagi:
>>> * 4) może zawierać cokolwiek i nie masz nad tym kontroli
>>> * wpis w logu ma być czytelny dla człowieka i maszyny
>>> * masz w kodzie móc dodać kolejne pola ad-hoc, bez edycji w innych
>>> plikach czy miejscach bieżącego pliku
>>>
>>
>> Nie ma większego problemu, jest kilka metod na rozwiązanie w zależności
>> od potrzeb. Może to boś ściśle typowane lub nie (variant, string). Czas
>> życia komunikatu zarządzany ręcznie (obiekty) lub automatycznie
>> (interface, open string, array of). Możesz mieć przeładowaną funkcję warn.
>>
>>
>> stringi są w Delphi automatycznie zarządzane i efektywnie
>> przekazywane. Podobnie dynamiczne tablice stringów. Parsowanie jest
>> trywialne. Mam zbór funkcji które zbudują taki komunikat (tablica
>> asocjacyjna) jak wskazałeś a sam logger w pełni asynchroniczny.
>
> Oczywiście. Drzewa zasłaniają ci las.
>
> Nie interesuje mnie czas życia tego stringa. Nie interesuje mnie
> przeciążanie funkcji warn, zwłaszcza że ona powinna być biblioteczna.
> To, co mnie interesuje, to definiowanie pól w komunikacie ad-hoc,
> w miejscu, w którym tworzę komunikat. *Bez przygotowań*, w tym bez
> deklarowania dodatkowych zmiennych tylko na potrzeby logowania.
>

Prawdopodobnie wcale nie interesuje Cie jakiekolwiek rozwiązanie tego
problemu.

Istotna jest jedynie elastyczność rozwiązania, komplikacja zapisu oraz
uzyskany efekt. Nieistotne jest czy to jest funkcja biblioteczna, czy
korzysta z takich czy innych konstrukcji językowych.

Nie interesuje Cię czas życia, bo nie masz na to wpływu,
nie interesuje Cię przeciążanie bo nie Perl nie ma takich możliwości

A mnie nie interesuje aby była biblioteczna, bo mam różne oczekiwania co
do logowania w zależności od rodzaju aplikacji/platformy.

Ale mimo to przykładowa notacja (kilka wariantów):

logger.warn( "coś się zepsuło"
+'file'+FileName+eol
+logger.param('errorcode,e.errorcode)
+'obiekt=>'+logger.asAddress(myClass)
+'warning=> uwaga');

mogę przesłać wszystko, dowolną ilość pól,
nic nie deklaruję
mogę przesłać teksty i obiekty

funkcja może być biblioteczna, z takiej czy innej biblioteki :
rozmawiamy o możliwościach języka


A mogę dołożyć własne wymagania:
nazwie pliku musi zawsze towarzyszyć jego zawartość (albo analogicznie
inna korelacja danych sprawdzana w momencie kompilacji: chodzi o to aby
zminimalizować błędy niepełnego wysłania informacji do loggera)






--
Darek

do góry

On 2013-01-21, Stachu 'Dozzie' K. <d...@g...eat.some.screws.spammer.invalid> wrote:
> Było trochę podane, wystarczyło się ustosunkować.

Niby co było podane?
Rzuciłeś nazwami kilku języków i kilku programów. Tak się składa, że
w sporej części używam tego samego i zobacz, jak wiele nas różni.

>> No i nie bardzo widzę powody, żeby miał Ci udowadniać, jakie to IDE
>> są świetne. Nie sprzedaję, nie reklamuję, a nawet ich nie tworzę.
> To po co próbujesz (do tego nieudolnie) to robić?

Bo chciałeś.

> Ta, używałem tego Visual Studio. Edytor czasem wcina mi blok tekstu,
> który wklejam, a czasem nie. Niech się, kurna, zdecyduje: albo pomaga
> *zawsze*, albo nie pomaga *nigdy*.

Nie wiem, czy przez 10 lat korzystania kiedykolwiek wkleiłem jakiś
fragment kodu do VS. Może z dokumentacji online jakieś drobiazgi?
W każdym razie nie mam pojęcia, o co Ci chodzi z tym wcinaniem...

> Ale OK, zgoda, niech sobie będzie najlepszy. Może ja się nie umiem z nim
> dogadać.

Tak właśnie sądzę.

> A skąd pomysł że teraz, po kilku latach pracy, będę się chciał nagle
> przekwalifikowywać na programistę?

No nie wiem. Kilka lat to dość mało wobec tych ~50, które Cię czekają.
Nie wiem czym się zajmujesz, ale czy chcesz to robić przez pół wieku?
Ja nie mam zamiaru całe życie klepać raportów przy kompie. Może jak
się dorobię, zostanę rolnikiem? Albo przewodnikiem. Oba zawody
przyjemne i przyjazne staruchom :].

pozdrawiam,
PK

do góry

On 2013-01-21, Stachu 'Dozzie' K. <d...@g...eat.some.screws.spammer.invalid> wrote:
> Taką robotę zleca się klepaczowi kodu, a nie sysadminowi. Nawet jeśli
> ten sysadmin ma przygotowanie programistyczne. Takie są realia.

Och ależ nie są :)
Aplikację "na jutro" zleca się nie koderowi tylko właśnie często
temu najlepszemu w zespole (tzn. analitykowi). Przy tak szybkim
projekcie często nie ma czasu na tradycyjny podział obowiązków
w zespole, a szeregowi koderzy rzadko mają niezbędne umiejętności.
Przypominam, że projekt "na jutro" robi się szybko kosztem jakości
kodu, ale musi robić to, czego się wymaga.

BTW: Nie wiem jak to jest teraz, ale kilka lat temu to się ludzie
z administratorów raczej nabijali. Kiedy studiowałem informatykę,
popularne były żarty o byciu administratorem po studiach (trochę jak
o kserowaniu po ekonomii i wykładaniu glazury po fizyce :)).
Naprawdę masz taką fajną i dobrze płatną pracę, czy po prostu trochę
koloryzujesz?
Bez obrazy i bez nerwów - szczerze pytam, bo nie wiem.

pozdrawiam,
PK

do góry

On 2013-01-22, darekm <d...@e...com> wrote:
>>>> Proszę bardzo, jedziesz. Ja w Perlu robię tak:
>>>> #v+
>>>> $logger->warn(msg "coś się zepsuło",
>>>> file => $filename, errorcode => $?, warning => $msg);
>>>> #v-
>>>>
>>>> Masz obiekt loggera z metodą do wysyłania ostrzeżeń. Potrzebujesz podać:
>>>> 1) własny komunikat
>>>> 2) nazwę pliku, którego np. otwarcie sprawiło problem
>>>> 3) kod błędu (errno lub analogiczny)
>>>> 4) treść komunikatu od systemu
>>>> Uwagi:
>>>> * 4) może zawierać cokolwiek i nie masz nad tym kontroli
>>>> * wpis w logu ma być czytelny dla człowieka i maszyny
>>>> * masz w kodzie móc dodać kolejne pola ad-hoc, bez edycji w innych
>>>> plikach czy miejscach bieżącego pliku
[...]
>> Oczywiście. Drzewa zasłaniają ci las.
>>
>> Nie interesuje mnie czas życia tego stringa. Nie interesuje mnie
>> przeciążanie funkcji warn, zwłaszcza że ona powinna być biblioteczna.
>> To, co mnie interesuje, to definiowanie pól w komunikacie ad-hoc,
>> w miejscu, w którym tworzę komunikat. *Bez przygotowań*, w tym bez
>> deklarowania dodatkowych zmiennych tylko na potrzeby logowania.

> Prawdopodobnie wcale nie interesuje Cie jakiekolwiek rozwiązanie tego
> problemu.

Oczywiście że interesuje mnie. Interesuje mnie rozwiązanie problemu,
który postawiłem. Mam utworzyć wpis i ten wpis posłać do miejsca
składowania logów. Po co mi do tego zadania znać jest czas życia obiektu
reprezentującego wpis?

> Istotna jest jedynie elastyczność rozwiązania, komplikacja zapisu oraz
> uzyskany efekt. Nieistotne jest czy to jest funkcja biblioteczna,

Nieistotne? Powiedziałbym że całkiem ważne. Ja nie chcę *pisać* loggera,
ja chcę go *użyć*. Znaczy -- powinien pochodzić z gotowej biblioteki.

> Nie interesuje Cię czas życia, bo nie masz na to wpływu,
> nie interesuje Cię przeciążanie bo nie Perl nie ma takich możliwości

Perl nie ma możliwości przeciążania? Mówisz o wywoływaniu funkcji
z różnymi typami parametrów czy o zmianie znaczenia operatorów
zdefiniowanych w języku dla własnych typów? Bo oba w Perlu występują
i nie wiem do czego pijesz.

> A mnie nie interesuje aby była biblioteczna, bo mam różne oczekiwania co
> do logowania w zależności od rodzaju aplikacji/platformy.

A jakie, że nie da się tego zawrzeć w bibliotece? Ja sobie takich nie
wyobrażam, ale ja głównie piszę daemony i programy wierszopoleceniowe,
więc mam dość wąską perspektywę.

> Ale mimo to przykładowa notacja (kilka wariantów):
>
> logger.warn( "coś się zepsuło"
> +'file'+FileName+eol
> +logger.param('errorcode,e.errorcode)
> +'obiekt=>'+logger.asAddress(myClass)
> +'warning=> uwaga');
>
> mogę przesłać wszystko, dowolną ilość pól,
> nic nie deklaruję
> mogę przesłać teksty i obiekty

Ah so. I twoim zdaniem taki ręcznie sklejony string jest *równoważny*
przekazaniu loggerowi wpisu ze strukturą? Nawet się nie upieram żeby ta
struktura była zagnieżdżona. Nie będę nagle wprowadzać nowego warunku,
skoro poprzednio o nim zapomniałem.

Powiedz mi, z jakiego powodu nie odtworzyłeś warunków zadania? Ze
złośliwości? Przez przeoczenie? Czy byłeś za głupi żeby zadanie
zrozumieć? Wolałbym nie zakładać ostatniej możliwości, bo ta gałąź wątku
byłaby bezsensowna od samego początku.

> funkcja może być biblioteczna, z takiej czy innej biblioteki :
> rozmawiamy o możliwościach języka

O możliwościach języka, ale na podstawie konkretnego scenariusza użycia.

> A mogę dołożyć własne wymagania:
> nazwie pliku musi zawsze towarzyszyć jego zawartość (albo analogicznie
> inna korelacja danych sprawdzana w momencie kompilacji: chodzi o to aby
> zminimalizować błędy niepełnego wysłania informacji do loggera)

Da się zrobić. Tak, bez uruchomienia kodu (zakładając, że nie liczymy
funkcji eval) i bez ręcznego parsowania Perla. Tylko że Perl nie jest
statycznie typowany, you know. Nie był przewidziany do takich rzeczy.

Zresztą jestem ciekawy, jak chcesz to zrobić w Delphi utrzymując moje
wymagania (głównie możliwość dokładania pól ad-hoc), a tym bardziej przy
twojej propozycji w postaci klejenia stringa, który jest potem
przekazywany loggerowi.

--
Secunia non olet.
Stanislaw Klekot

do góry

On 2013-01-22, PK <P...@n...com> wrote:
> On 2013-01-21, Stachu 'Dozzie' K. <d...@g...eat.some.screws.spammer.invalid>
wrote:
>>> No i nie bardzo widzę powody, żeby miał Ci udowadniać, jakie to IDE
>>> są świetne. Nie sprzedaję, nie reklamuję, a nawet ich nie tworzę.
>> To po co próbujesz (do tego nieudolnie) to robić?
>
> Bo chciałeś.

No to w końcu widzisz powody czy ich nie widzisz? Zdecyduj się.
Chociaż przyznam, że w tym miejscu już niepokojąco ocieram się
o sofistykę, więc może nie drążmy więcej tematu motywacji do
dyskutowania.

>> A skąd pomysł że teraz, po kilku latach pracy, będę się chciał nagle
>> przekwalifikowywać na programistę?
>
> No nie wiem. Kilka lat to dość mało wobec tych ~50, które Cię czekają.

I uważasz że nagle zapragnę pisać programy na akord, żeby je parę dni
później wyrzucać? Coś chyba nie działa.

Bo przy ciekawszych rzeczach kwestie doboru edytora/środowiska to sprawa
wtórna i raczej nikt nie będzie mi wmuszać interfejsu wprowadzania kodu
do komputera.

> Nie wiem czym się zajmujesz, ale czy chcesz to robić przez pół wieku?

Uważam że tak, ale liczę się z tym, że zmienię zdanie.

Zdarzyło mi się już zmieniać kierunek kształcenia, więc choć nie widzę
powodów, dla których miałoby mi się znudzić aktualne zajęcie, liczę się
z możliwością zmiany zawodu.

> Ja nie mam zamiaru całe życie klepać raportów przy kompie. Może jak
> się dorobię, zostanę rolnikiem? Albo przewodnikiem. Oba zawody
> przyjemne i przyjazne staruchom :].

To dobrze, że masz jakąś wizję, życzę w takim razie zdrowia. Mnie cieszą
inne rzeczy i trochę co innego widzi mi się robić w wieku
okołoemerytalnym.

--
Secunia non olet.
Stanislaw Klekot

do góry

On 2013-01-22, PK <P...@n...com> wrote:
[cut-n-paste]
> Bez obrazy i bez nerwów - szczerze pytam, bo nie wiem.

Tę część odebrałem jako szczere zainteresowanie i absolutnie się nie
obrażam.

> BTW: Nie wiem jak to jest teraz, ale kilka lat temu to się ludzie
> z administratorów raczej nabijali. Kiedy studiowałem informatykę,
> popularne były żarty o byciu administratorem po studiach (trochę jak
> o kserowaniu po ekonomii i wykładaniu glazury po fizyce :)).
> Naprawdę masz taką fajną i dobrze płatną pracę, czy po prostu trochę
> koloryzujesz?

Naprawdę mam taką fajną robotę. Ustalmy tylko od razu, że trochę czymś
innym jest coś, co ostatnimi czasy nazywam on-site supportem (pomoc
użytkownikom, opieka nad desktopami, również konserwacja drukarek
i innego sprzętu okołokomputerowego), trochę innym jest zarządzanie
siecią, a jeszcze czymś innym -- serwerami.

Ja się zajmuję tym ostatnim, konkretnie -- serwerami linuksowymi, stroną
systemu operacyjnego. W zespole jest nas około dziesięciu, a pod opieką
mamy Red Haty ({4,5,6} x {i386,x86_64}) w liczbie 500+, używane przez
programistów w kilkunastu oddziałach (bliżej 20 niż 10; nie pamiętam
dokładnie).

Programiści używają głównie toolboksa opracowanego i rozwijanego
specjalnie na potrzeby tej organizacji. Naszym zadaniem jest
(niekoniecznie w kolejności, lista nie wyczerpująca zadań)
* instalacja i aktualizacja softu (toolboksa i softu z systemu
operacyjnego)
* doprowadzenie serwerów do i utrzymanie ich w stanie używalności
(ustawianie i rekonfiguracja klientów NIS/LDAP/NFS, hypervisorów
wirtualizacji, NTP, softu do komunikacji ze sprzętem (HP ProLiant
Support Pack), jednolitego środowiska w shellu dla użytkowników
i tak dalej)
* zbieranie i przetwarzanie informacji o pracy tych maszyn
(obciążenie, lista i wersje uruchamianych przez użytkowników
elementów wspominanego już toolboksa, operacje rekonfiguracji
wykonane na serwerach)
* utrzymanie repozytoriów z własnymi narzędziami
* opracowywanie nowych narzędzi wspomagających pracę z tą liczbą
serwerów
* przygotowanie usług (np. Samba, LXC) do wdrożenia na serwerach

Oczywiście nie jesteśmy sami. Trzeba doliczyć masę techników, którzy
montują sprzęt w szafach i instalują system operacyjny na serwerach,
ludzi ze wsparcia technicznego, którzy debuggują problemy zgłaszane
przez użytkowników i tak dalej.

Źródłem "fajności" tej roboty jest skala (ekipy w tym momencie nie
liczę, choć jest rewelacyjna). Może i 0.5k maszyn nie jest środowiskiem
_ogromnym_ (koledzy po fachu bywa że miewają i 17k pod opieką), ale
z pewnością nie co dzień się takie spotyka.

Właśnie z powodu skali dość często programuję, a między językami się
przełączam albo dlatego, że narzędzie przez nas używane jest w takim
napisane (pluginy do Fluentd to Ruby), albo dlatego, że dany język
oferuje coś, czego inne nie mają (np. Python -- obecność w świeżo
zainstalowanym systemie i moduł kliencki do XML-RPC w cenie), albo
dlatego, że model pracy jest odpowiedni do zadań (myślę tu o make), albo
trzeba zdebuggować niedziałające narzędzie (C, PHP, Java). Choć zdarzają
się też inne powody zmiany bieżącego języka.

--
Secunia non olet.
Stanislaw Klekot

do góry