Ile mogą jej płacić ?

0

http://it.krd.pl
tam jak przewiniecie w dół na "bohaterowie" (49%). i wybierzecie blondynkę najbardziej z prawej to ile ona moze tu zarabiac?

albo ta druga babeczka, druga od prawej "programistka SQL" ? co ona samym sqlem programuje?

4

Miska ryżu na umowę o dzieło.

3

Napisz do niej z pytaniem.

2

Śmieszna strona, ale trochę za ciężko chodzi (intel i5 bez dodatkowej karty graficznej).

0

Podoba mi się podejście z jajem do tematu. Prawy górny róg-i'm not a bug, i'm a feature ;)

0

taki offtop => tutaj troche wiecej jak to wykonali;) na blogu goscia, ktory tam pracuje http://mnajman.com/Blog/PostDetails/Efekt-Website-Parallax-mmark-studium-przypadku

0

Stronka całkiem spoko, myśle że znajdą chętnych.. :) Ale grafik trochę za mocno zafantazjował..

0

Ciężka strona. Tu coś lata, tam się rozwija, siam się kręci... uch.

0

Cześć,

Tu gość, który współtworzył stronę :) Miło przeczytać, że strona generalnie się podoba (i super, że ktoś zauważył naszego ‘robaka’! ). Prawdą jest, że witryna jest dość ciężka i wymaga mocnego sprzętu, ale tutaj boleśnie przekonałem się, że teoria != praktyka. Przeglądarki, mimo że nowoczesne , mają problem z obsługą tak wielu jednocześnie animujących się obiektów. Więc następna odsłona powstanie już pewnie w HTML5 (bo Flashowi mówimy zdecydowanie nie! ). Co do fantazji grafika – również prawda, bo koncept witryny narodził się po kilku piwach :)

Pozdrowienia od całej ekipy IT KRD

2

Przeglądarki, mimo że nowoczesne , mają problem z obsługą tak wielu jednocześnie animujących się obiektów

tyle, że tam się nic specjalnie nie rusza. BTW. jak to jest, że można zrobić grę w HTML5, w której się animuje kilkadziesiąt czy kilkaset divów i nie przycina -- a ludzie robią parę obiektów animowanych na krzyż na stronie i wszystko nagle przycina? Gry (na divach) są jakoś cudownie chronione przed zamulaniem? (po części może to być prawda, ruszające się małe sprajty pewnie będą mniejszym obciążeniem niż duże animowane obrazki z zagnieżdżonym markupem HTMLowym i zagnieżdżonymi regułami... Ale z drugiej strony jest tyle stron pisanych w HTMLu i CSS które da się otworzyć bez zamułki. Może jakiś błąd sztuki osób, które się tym zajmują, a nie wina technologii? (BTW ja tam flasha nie widzę, nie wiem jak było od strony developera, czy to było kompilowane z Flasha do HTML, bo na produkcji wszystko jest w HTML, tyle że nie 5 a XHTML, wg doctype).

Korzystamy z popularnych języków i technologii: od Windows Forms, poprzez WPF, WCF, ASP (Webforms i MVC), kończąc na Html i JavaScript.

sugerowanie, że korzystanie z "popularnych języków i technologii" jest oznaką profesjonalizmu.

5 MLN LINII KODU
I CIĄGLE ROŚNIE

sugerowanie, że liczba linii kodu i jej wzrost to dobra rzecz

16 MLN ROZRÓŻNIANYCH
KOLORÓW

Dokładamy starań, by na naszych witrynach używano więcej niż dwóch kolorów.

sugerowanie, że strony powinny być ciapate, bo im więcej kolorów tym lepiej.

Każdy specjalista ma ulubione narzędzia. Mamy własny serwer NuGet, używamy Enterprise Architect, dbamy o kontrolę wersji (GIT, Mercurial).

sugerowanie, że każdy powinien używać innych narzędzi do pracy (jeden GITa, drugi Mercuriala?)

Pasja i rozwój - najnowsze rozwiązania, sprzęt, frameworki

sugerowanie, że żeby otworzyć tę stronę potrzebny jest "najnowszy sprzęt", bo na starszym nie pójdzie (co akurat jest prawdą...)

0

Więc następna odsłona powstanie już pewnie w HTML5

Jestem trochę w szoku, że tej wersji nie zrobiliście w html5...

1
szalonyfacet napisał(a):

taki offtop => tutaj troche wiecej jak to wykonali;) na blogu goscia, ktory tam pracuje http://mnajman.com/Blog/PostDetails/Efekt-Website-Parallax-mmark-studium-przypadku

fajne. Cytaty:

Poza opracowaniem koncepcji i stworzeniem projektu graficznego, kluczowym wyzwaniem technicznym okazało się użycie efektu Parallax i wykorzystanie pełni jego możliwości w praktyce Wikipedia.

Budowanie własnego frameworka do obsługi tego efektu, byłoby czasochłonne i zwyczajnie nieopłacalne. Po wstępnym rozeznaniu gotowych rozwiązań, postawiłem na plugin skrollr ( Github ).
TL;DR: wykonawca nie chciał tego samemu robić, więc użył gotowego pluginu o nazwie skrollr.

W wielkim skrócie: moim zdaniem wtyczka jest godna polecenia - jest przede wszystkim bardzo wygodna w użyciu. Nawet osoba, która nie potrafi programować w JavaScript powinna sobie poradzić w pracy z tą biblioteką. Mimo jej niewątpliwych zalet, muszę jednak przyznać, że podczas pracy z nią natknąłem się na kilka dość istotnych problemów, które postaram się poniżej opisać. Na początek jednak plusy dodatnie:

ZALETY BIBLIOTEKI SKROLLR

  • Wygoda

Biblioteka pozwala na bardzo wygodne definiowanie animacji poszczególnych elementów. Wszystko odbywa się bezpośrednio w kodzie html (domyślnie), bez angażowania JavaScript.

TL;DR: wykonawca albo nie znał JavaScriptu, albo mu się nie chciało w JavaScripcie pisać, a plugin umożliwiał mu możliwość niepisania w tym języku.

Dostarczona z wtyczką ściąga ( Anchor Guide PDF ), może na początku wydawać się przytłaczać mnogością możliwości, ale po kilku godzinach prób i błędów wszystko staje się jasne i intuicyjne.

TL;DR: nawet używając gotowej wtyczki poświęcił na to "kilka godzin prób i błędów" (swoją drogą napisanie od zera wtyczki do parallaxa też by więcej niż kilka godzin nie zajęło... )

WADY I PROBLEMY

  • Wycieki pamięci:

Aktualna wersja (0.6.26) użyta na stronie powodowała znaczne wycieki pamięci na przeglądarce Google Chrome. Strona po kilkunastu minutach bezczynności potrafiła zajmować w pamięci ponad 1 GB, a zużycie pamięci nadal nieustannie rosło. Dotyczyło to również sytuacji, kiedy przeglądarka była zminimalizowana. Powrót do starszej wersji (0.6) pluginu rozwiązał problem.

TL;DR: na dodatek plugin ten sprawiał problemy z pamięcią (czyli był zbugowany).

Wydajność:

Po uruchomieniu strony na środowisku produkcyjnym pojawiła się niemiła niespodzianka. Odpalenie jej na słabszych maszynach (czyli niedeveloperskich wyposażonych w mocne procesory i sporą ilość pamięci) powodowało jej wyraźne klatkowanie i widoczne opóźnienie reakcji na żądania użytkownika.

TL;DR: praktyka pokazała, że plugin okazał się niewydajny.

Nie sądzę, żeby winny był sam plugin (nie korzysta on z wolnego setTimeout, ale z requestAnimationFrame.

TL;DR: mimo, że w teorii miał być wydajny bo przecież... korzystał z requestAnimationFrame xD

sugerowanie, że podmiana setTimeout na requestAnimationFrame jest receptą na wszystkie bolączki wydajności, a samo korzystanie z requestAnimationFrame sprawia nieuchronnie, że nasz kod się wykonuje szybko.

Przydała się również kompresja wszystkich plików graficznych i usunięcie z plików fontów nieużywanych znaków – ostatecznie cała witryna waży jedynie ok. 5 MB.

TL;DR: sugerowanie, że jeśli "cała witryna waży ok. 5 MB." to jest to mało.

Wbudowany we wtyczkę mechanizm płynnego animowania podczas przewijania strony ( skrollr demo ) nie jest idealny. Po pierwsze nie zapewnia naprawdę pełnej płynności, a dodatkowo nie wspiera inercji (efekt powszechnie występujący we wszystkich systemach mobilnych). Tutaj musiałem oprogramować proste rozwiązanie w JS, które polega na ręcznej obsłudze kółka myszki i klawiszy nawigujących i odpowiednim animowaniu właściwości scrollTop.

TL;DR: mimo zastosowanego pluginu, i tak trzeba było ręcznie napisać trochę kodu w JS (mimo, że plugin miał umożliwiać niepisanie w JS).

  • Kompatybilność

Uruchomienie stron z bardziej zaawansowanymi efektami (niż tymi użytymi w wersji demo) na starszych przeglądarkach (rodzina IE, stare wersje Firefox) objawia się szeregiem niepożądanych efektów. Jest to m.in. brak płynności przewijania, efekty drgania obrazów lub wyświetlaniem elementów DOM w niepoprawnych pozycjach. Na najnowszych wersjach Chrome i Firefox nie występują żadne z opisanych problemów. Internet Explorer w wersji 12 może też będzie działał bezproblemowo :)

TL;DR: akapit ten stoi w sprzeczności z jednym z poprzednim, gdzie mowa była o tym, że na maszynach niedeveloperskich występowały problemy z wydajnością.

Mimo złośliwości w moim poście to jednak uważam, że należą się spore gratki za opisanie tego case study na blogu, ponieważ ludzie uczą się na błędach (swoich albo cudzych), i o ile strona wyszło kiepska to jednak zdanie sobie sprawy z błędów i opisanie tego dla reszty programistów jest czymś bardzo okej :)

Wniosek (mój) jest taki, że chęć pójścia na skróty i użycia gotowego pluginu, bo napisanie czegoś samemu byłoby "czasochłonne i zwyczajnie nieopłacalne." spycha ludzi często na manowce, kiedy to użycie gotowego rozwiązania generuje cały łańcuszek problemów i sprawia, że więcej czasu poświęcamy na zabawę z pluginem, niż byśmy napisali coś samemu; a efekt okazuje się mierny.

2

tyle, że tam się nic specjalnie nie rusza. BTW. jak to jest, że można zrobić grę w HTML5, w której się animuje kilkadziesiąt czy kilkaset divów i nie przycina -- a ludzie robią parę obiektów animowanych na krzyż na stronie i wszystko nagle przycina? …

Gry są najczęściej robione przy użyciu HTML5 i elementu Canvas. To zupełnie inna filozofia tworzenia i działania takiego rozwiązania niż klasyki: Html + CSS + Javascript. Flasha nie użyliśmy i nie użyjemy.

Korzystamy z popularnych języków i technologii: od Windows Forms, poprzez WPF, WCF, ASP (Webforms i MVC), kończąc na Html i JavaScript.
sugerowanie, że korzystanie z "popularnych języków i technologii" jest oznaką profesjonalizmu.

To czysta informacja dla potencjalnego kandydata. Od razu wie, że nie programujemy np. w Javie, czy Ruby on Rails.

5 MLN LINII KODUI CIĄGLE ROŚNIE
sugerowanie, że liczba linii kodu i jej wzrost to dobra rzecz

Doskonale wiemy, że stosowanie liczby linii kodu jako miary jakości oprogramowania jest porażką. Użyliśmy tutaj tej metryki w zupełnie innym celu – uświadomieniu potencjalnemu kandydatowi z jak dużymi i skomplikowanymi systemami mamy do czynienia na co dzień.

16 MLN ROZRÓŻNIANYCH KOLORÓW
Dokładamy starań, by na naszych witrynach używano więcej niż dwóch kolorów.
sugerowanie, że strony powinny być ciapate, bo im więcej kolorów tym lepiej.

To był wyłącznie żart (takie nawiązanie do dowcipu, o tym ile kolorów rozróżnia prawdziwy facet :) ).

Każdy specjalista ma ulubione narzędzia. Mamy własny serwer NuGet, używamy Enterprise Architect, dbamy o kontrolę wersji (GIT, Mercurial).
sugerowanie, że każdy powinien używać innych narzędzi do pracy (jeden GITa, drugi Mercuriala?)

Zgodnie z filozofią metodyk zwinnych zespoły programistyczne mają dużą autonomię w kwestii doborów narzędzi. Same decydują jakich narzędzi użyć w określonych projektach.

Pasja i rozwój - najnowsze rozwiązania, sprzęt, frameworki sugerowanie, że żeby otworzyć tę stronę potrzebny jest "najnowszy sprzęt", bo na starszym nie pójdzie (co akurat jest prawdą...)

Nie w każdej pracy standardem jest i5 + SDD + 2 duże monitory – u nas jest. Faktem jest też, że właściwie każdy ciekawie zapowiadający się framework, która się ukazuje (albo nowa wersja, już przez nas używanego) bierzemy na tapetę i robimy "proof of concept". Nie babrzemy się w MVC 1.0 albo Web forms – stąd takie taki przekaz. A że strona będzie kulała na starszym sprzęcie – to wiemy i akceptujemy.

LukeJL – zapraszamy do nas na rozmowę. Jeśli zaproponujesz równie dobre (albo i lepsze, czego Ci życzę) rozwiązania, na pewno będziesz zadowolony z projektów, komfortu pracy i oczywiście wynagrodzenia.

2
Michał Webmaster napisał(a):

Doskonale wiemy, że stosowanie liczby linii kodu jako miary jakości oprogramowania jest porażką. Użyliśmy tutaj tej metryki w zupełnie innym celu – uświadomieniu potencjalnemu kandydatowi z jak dużymi i skomplikowanymi systemami mamy do czynienia na co dzień.

Ale co ma liczba linii kodu do wielkości i skomplikowania projektu?
Systemy, w których kod można skrócić 10 razy wprowadzając jedynie DRY, SOLID i wzorce, nie są wcale rzadkością. A istnieją też systemy, w których kod można w ten sposób skrócić 100 razy.
Po takiej reklamie widzę firmę jako słabą, skoro musi się chwalić liniami kodu, zamiast czymś sensownym.

0

Fajne zagadki rekrutacyjne. Ale podpowiedź do pierwszych 3 w zasadzie zbędna. :P

0
dam1an napisał(a):

Fajne zagadki rekrutacyjne. Ale podpowiedź do pierwszych 3 w zasadzie zbędna. :P

Mysle ze do czwartej tez, bo zapis tych kodow jest tak specyficzny ze na pierwszy rzut oka widac co to jest bo kto nie pozna morse'a, binarek, hexa i base64.

mnie sie rzucilo setki brek w kodzie i id z nazwami "aaa" i "abc", widac ze pracuja tam ludzie, ktorzy czesto zostawiaja babolki na produkcji, ale dla mnie to lepsze niz zespol Top koderow ;)

1 użytkowników online, w tym zalogowanych: 0, gości: 1