Wypowiedzi
-
Małgorzata Grelich:
Z doświadczeń osoby, która przeprowadziła ponad 1900 spotkan rekrutacyjnych.
TOTALNIE nie ma znaczenia, czy ktoś ma inz czy mgr.
Ma lub miewa znaczenie.
Pamiętam z Motoroli, że na Soft Eng było minimum 2 lata pracy i inż, na Senior Soft Eng było minimum 2 lata pracy i mgr lub 4 lata pracy i inż. A to się już różniło finansowo.
Inż/mgr mają głównie znaczenie dla ludzi, którzy zaczynają pracę, albo pracują krótko. Sam gdybym miał wybierać kogoś do teamu to bazując na CV bym raczej wybrał mgr, choć rozmowa i testy mogłyby to zmienić.
-
Oskar Jarczyk:
Ciekawe są te opinie. Większość moich znajomych w Warszawie w pierwszej pracy nie dostała więcej niż 2000-2200 zł netto (programiści, projektanci, młodsi analitycy). Żeby dobić do 5000 brutto trzeba już na studiach przepracować z 2 lata. Wystarczy spojrzeć na ilość wysłanych CV na jedno ogłoszenie programistyczne (~50-100), by się przekonać, ze brak informatyków w Polsce jest mitem.
Nie jest mitem. Po prostu wielu absolwentów jest niedouczonych, albo nie zna angielskiego.
Są podobno "uczelnie", które przez całe studia wkładają do głów studentów tylko C#, albo olewają algorytmy i struktury danych.
Jak spytać wielu co to jest np. metoda wirtualna to nie wiedzą, albo żeby podali odpowiedź na proste pytanie "jaka jest różnica między final, finally i finalize i co każde z nich robi/oznacza?".
Nie wiem jak to jest w całym biznesie, ale w wielu firmach już na przeglądaniu CV odpada 90% CV, później na 1 miejsce są np. 3 osoby wskazywane jako możliwe i dopiero odbywają się rozmowy. W takim Google mają jeszcze zabawniej.
Może i kandydatów jest wielu, ale niestety nie wszyscy się nadają do przyjęcia.Przemysław Rumik edytował(a) ten post dnia 26.10.11 o godzinie 12:39
-
Marian Nowert:
Witam chciałem poruszyć kontrowersyjny temat płacowy. Nie rozumiem dlaczego w różnych miastach w Polsce są tak rozbieżne stawki płacowe. Stawki na start dla programisty Java EE świeżo po studiach :
Warszawa 3600 zł na rękę
Wrocław 2800 zł na rękę
Poznań 2800 zł na rękę
Łódź 2400 zł na rękę
Lublin 2100 zł na rękę
Dlaczego jest taka rozbieżność, macie jakiś swój przedział cenowy ?
Coś nieteges masz te dane.
Sam pamiętam, że w 2004 roku idąc pracować do Motoroli w Krakowie dostałem więc niż Ty tu piszesz jako Warszawę. Teraz z tego co wiem absolwenci, którzy dostają się do wielu firm w Krakowie dostają więcej niż te kwoty i to zwykle dużo więcej.
A co do różnicy to tu akurat działa rynek, w Warszawie, Krakowie czy Wrocławiu jest wiele firm IT szukających programistów i przez to ceny za prace są wyższe, a ilość programistów jest skończona.
-
A czy ja twierdzę, że read dział tak jak piszesz? Nie.
Ale już moja metoda tak [przy braku blokowania] i robi dokładnie to czego chce pytający, czyli spełnia życzenie "Zależy mi żeby można było odebrać cały wysyłany pakiet". Robi to bez dodawania żadnego overheadu.
To co Ty implementujesz to prosty protokół do przesyłania danych binarnych w tunelu.
W implementacji SocketInputStream (z głowy piszę nazwę klasy, ale jest at least podobna) read zwraca -1 tylko wtedy gdy jest EOF. Do socketRead0 jest przekazywany bufor, offset, długość i timeout. Metoda socketRead0 jest natywna i rzucić może IOException.
read zwraca więc albo -1 (gdy jest EOF), albo gdy jest nieblokujące tablicę danych (o maksymalnie tej długości, którą się mu przekazało), gdy jest blokujące to jeśli są dane to zwróci nam tablicę z danymi (pełną lub nie, ale wtedy to znaczy, że jest już EOF) lub będzie wisieć i czekać na nowe dane (ewentualnie wyleci z racji timeout'u).
TCP/IP nie daje nic co by ułatwiało przesyłanie paczek w rurze. Nic nie stoi na przeszkodzie by sobie postawić połączenie, które będzie stało latami, ale wtedy nad TCP/IP trzeba zbudować protokół.
Prosty przykład to protokół GG w którym masz zawsze długość danych w danym "pakiecie".
Overhead zawsze jest konieczny jeśli chce się coś dodać, serializacja, a jeszcze serializacja z pakowaniem do GZIP ma nie dużego overheadu.
Moja metoda nie zadziała w przypadku połączenia gdzie stawiasz tunel, ale i w "wymaganiach" tego nie ma.
To co napisałeś w swoim kodzie to prosty protokół, który zakłada przesyłanie danych w tunelu, do tego zdecydowanie bardziej polecałbym serializację (jeśli przesyłane są dane, które będą dekodowane do obiektów), jeśli chodzi o przesyłanie poleceń to na 99% da się zbudować protokół w którym polecenia będą miały stałą długość, albo taki gdzie typ messega opisuje jego długość.
To co proponujesz też działa, implementujesz coś co służy do przesyłania po prostu danych binarnych.
Co do overheadu i przesyłania danych przez sieć to masz rację, ale przeceniasz overhead, bo overhead prawie cały (albo i cały) mieści się w pakiecie samym (jeśli jest wysyłany cały). Jeśli robisz tak, że najpierw przygotowujesz wszystko w pamięci i od razu piszesz to masz prawie pewność, że system wyśle pakiety pełnej długości, jeśli piszesz do strumienia w kawałkach to system może uznać, że lepiej wysłać już dane (czyli zrobić flush), a nie czekać do dopełnienia pakietu (IP) (prosty scenariusz to wysyłanie pliku, najpierw rozmiaru, a później otwieranie pliku i kopiowanie danych, wtedy może się okazać, że system uzna, że minęło zbyt wiele czasu i wyśle w 1 pakiecie tylko rozmiar pliku). To zależy od wielu rzeczy, sam miewałem przypadki że zmiana wersji Java'y powodowała na tej samej maszynie inne rozdzielanie danych po pakietach. Dlatego to co może się wydawać mieć mniejszy overhead może mieć w rzeczywistości większy. Dlatego lepiej przetestować sprawę, a nie stwierdzać, że coś będzie wolniejsze na drodze oświecenia.
W przypadku przesyłania całego pakietu danych (który może zostać podzielony na wiele pakietów IP) moja metoda działa dokładnie tak jak powinna, i nie da się tego szybciej zrobić (alokacja pamięci w Java'ie jest tania). No chyba, że przez użycie GZIPa do spakowania danych.
-
TCP to nadbudowa nad IP, która daje tunel. Tym tunelem wysyłane są dane. Rolą aplikacji jest obsłużenie protokołu zbudowanego nad TCP.
Po TCP leci HTTP, HTTPS, Telnet i wiele innych protokołów.
TCP to rura, do której z jednej strony wrzuca się dane, z drugiej je pobiera.
Na tej rurze buduje się protokół.
Gdy wrzucamy do tej rury dane to już sam stos TCP/IP decyduje jak je przesłać, TCP zapewnia nam jednak to, że po drugiej stronie dane te dostaniemy w takiej samej kolejności w jakiej je wysłaliśmy.
To wszystko.
Stąd w Java'ie można np. swobodnie zbudować protokół bazując na serializaci obiektów.
Nie jest istotne czy akurat system operacyjny zdecyduje, że będzie wysyłał pakiety IP po 512 bajtów czy krótsze. Nie jest nawet istotne w jakiej kolejności wyśle te dane, może sobie np. ten 1 MB podzielić na 90 tysięcy pakietów i wysyłać je od ostatniego do pierwszego, system operacyjny po drugiej stronie odbuduje to i do aplikacji poda 1 MB w odpowiedni sposób.
Problemem przy używaniu socketów jest to, że czasem mamy połączenie blokujące, które będzie czekało na dane i zamknięcie połączenia, a czasem takie które jest nieblokujące.
Kod który podesłałem podaje na wyjściu tablicę bajtów z której kod na wyższym rzędzie musi wyciągnąć dane co do tego czy chcemy "ciągnąć" jeszcze dalej czy nie (w przypadku gdy socket nie jest blokujący, bo gdy jest blokujący to po prostu dostaniemy wszystko bo natywna implementacja read (dokładniej socketRead0) będzie czekała aż nie dostanie wszystkiego (czyli aż socket nie zostanie zamknięty). Dlatego akurat tego kodu do np. zbudowania proxy które umie zrobić CONNECT nie polecał.
Najprostszy protokół do przesyłania danych jest taki:
private static class Data {
byte[] buf;
}
public void sendData(OutputStream os, byte[] buf) throws Exception {
ObjectOutputStream oos = new ObjectOutputStream(os);
Data d = new Data();
d.buf = buf; // zakładamy, że są w tym samym pliku
oos.writeObject(d);
oos.flush();
}
public byte[] getData(InputStream is) throws Exception {
ObjectInputStream ios = new ObjectInputStream(is);
Data d = (Data)ios.readObject(); // tu może lecieć ClassCastException
return d.buf;
}
voila, i ot cała tajemnica.
Jedyne czego nie można fajnie zrobić ze strumieniami w Java'ie to opakować GZIP streamów na socketowych (znaczy, móc można, ale nie działa z racji tego, że się biedactwo nie wie ile danych doczekać, ale można by było po prostu do sendData przesyłać wynik działania GZIP streamu na ByteArray streamie i już mamy kompresję danych zrobioną).
I przypominam jeszcze raz, że w Java'ie nazwy metod się pisze z małej litery.Przemysław Rumik edytował(a) ten post dnia 30.08.11 o godzinie 22:49
-
Dariusz Wawer:
Przemysław Rumik:
Ja bym zaczął od nauczenia się Java'y ;-)
To odważne stwierdzenie, zważywszy na zupełnie bezsensowny w tej sytuacji kod. Specyfika transmisji po socketach jest zupełnie inna niż np. czytania z pliku, do czego ten kod nadałby się świetnie.
Słowem, ja bym zaczął od poznania działania socketów:P
Problem w tym, że ten kod wielokrotnie służył do obsługi socketów ;-) Serwer proxy nawet na tym powstał :-) komunikacja z BTSami szła przy pomocy czegoś takiego.
Java ma bardzo małą kontrolę nad TCP, praktycznie jej nie ma, read sam obsługuje zabawę z available i podobne sprawy. Jak zależy komuś na tym by mieć pełną kontrolę to chyba tylko native zostaje bo w Java'ie wielu gwarancji nie ma.
Kod który podesłałem pozwala na traktowanie kanału TCP jako przezroczystego, jeden problem jest jak serwer nie jest na tyle miły by zamykać połączenia to się coś może sypać (np. można na read wisieć). Wtedy najprościej byłoby użyci nio.Przemysław Rumik edytował(a) ten post dnia 30.08.11 o godzinie 15:18
-
Ja bym zaczął od nauczenia się Java'y ;-)
Czytanie ze strumienia zrobić najprościej tak:
private byte[] get(InputStream is) {
ByteArrayOutputStream baos = new ByteArrayOutputStream();
byte[] buf = new byte[1024];
int count = 0;
do {
count = is.read(buf);
baos.write(buf,0,count);
} while (count!=1024);
return baos.toByteArray();
}
z palca piszę więc może się coś nie zgadzać.
Jeśli to ma być używane na mobile,np. w Androidzie to trzeba uważać z ByteArrayOutputStream (i ByteArrayInputStream) bo przy dużej ilości danych będzie problem z zajętością pamięci i można dostać OutOfMemory.
W Java'ie nazwy metod pisze się zawsze z małej litery.Przemysław Rumik edytował(a) ten post dnia 30.08.11 o godzinie 14:41
-
-
-
-
Cezar Pokorski:
Przemysław Rumik:
Akurat właściwości uważam za największą wadę C# ;-)
Czemu, czemu?
Bo to może prowadzić do dziwnych błędów.
Kod:
Point point = new Point();
point.x = 10;
point.y = 20;
powinien być równoważny kodowi:
Point point = new Point();
point.y = 20;
point.x = 10;
W sytuacji Java'y taki kod jest równoważny, w C# nie musi być. Jakiś dowcipniś może tak napisać settery, że np. ustawienie y bez x powoduje wyrzucenie wyjątku i powstaje magiczna zależność.
W Java'ie gdy widzę point.setX() to wiem, że mimo wszystko wołanie tego settera może mieć jakieś efekty inne niż ustawienie wartości i gdy mi poleci wyjątek to wiem kogo o to podejrzewać.
Co do delagatów to jak rozumiem chodzi o delegację funkcji i funkcje anonimowe, w Java'ie w to miejsce stosujemy klasy.
Właściwie to nie chodziło mi tyle o same delegaty, co o wygodną obsługę zdarzeń, która się na nich opiera. W Javie typowa konwencja to Listenery (przy okazji nowe interfejsy...), gdzie trzeba dopisać kilka funkcji i spamiętać przekazywane im wartości, podczas gdy w C# zapisy te są nieco krótsze, deklarujemy postać niezbędnej funkcji, a by przypisać zdarzenie wystarczy zrobić += naszaMetoda.
Tak mi się przynajmniej w tej chwili wydaje :)
Większość interfejsów dla Listener'ów ma odpowiednie Wrapper'y, w których wystarczy zaimplementować pojedynczą funkcję :-)
O J# i JVM w .NET wiem :) Aczkolwiek to właśnie działa trochę w przeciwnym kierunku niż ten, o którym tu sobie gdybamy :)
A oglądałeś to http://www.mainsoft.com/ ? Nie wiem czy się to do czegoś nadaje, ale może warto się przyjrzeć.
Choć wydaje mi się, że jednak lepiej przejść po prostu na jasną stronę mocy i zacząć pisać w Java'ie ;-) tylko jak mogę coś sugerować, to bez przenoszenia konwencji z C#. Memberzy klasy mają być z małej literki, a nazwa klasy z dużej :-)
-
Dodane później:
Może to Ci pomoże http://www.mainsoft.com/
Akurat właściwości uważam za największą wadę C# ;-)
Co do delagatów to jak rozumiem chodzi o delegację funkcji i funkcje anonimowe, w Java'ie w to miejsce stosujemy klasy.
Dla mnie osobiście C# to Java zaśmiecona ficzerami z Delphi, ale zdaję sobie sprawę z tego, że jestem stronniczy :-) Bo w przypadku Java'y miałem zawsze do czynienia z dobrym kodem w dobrych firmach, a w przypadku C# ze złym kodem w słabych firmach ;-)
Co do C# na JVM to chyba jedyną drogą była J# ale to w drugą stronę, w drugą stronę działa też IKVM, sam niestety nie słyszałem o komplikacji C# do bytecodu Java'y. Pewnie nikt tego nigdy na poważnie nie potrzebował.Przemysław Rumik edytował(a) ten post dnia 03.05.09 o godzinie 19:29
-
A może Alice?
Co prawda nie jest to gra, a bardziej zabawa w budowanie przy pomocy Java'y animacji 3D, lub opowiadanie historyjek, ale podobno nieźle działa jako pomoc dydaktyczna.
http://alice.org/
-
Karolina K.:
To chyba nie świat Dysku
ale zawsze to nasz Terry Pratchett
To Ziemia w XIX wieku ;-) ale trochę inna.
Trochę obawiam się tłumaczenia, bo to jednak nie PWC, a dla tego tłumacza to jak się wydaje pierwsza książka pterry'ego.
Już samo tłumaczenie tytułu może być dyskusyjne, bo z tonu książki i tego, że Mau i inni zawsze mówią o wyspie i ludzie go zamieszkującym "Nation" bardziej na miejscu byłoby chyba tłumaczenie "Naród".
Do plusów książki należy zaliczyć na pewno Richarda Dawkinsa, o którym mowa pod koniec książki ;-)
-
Jedna rzecz smuci w naszym wydaniu Nauki Świata Dysku III. Błędy.
Masa błędów w datach.
Sprawdziłem z oryginałem i tam błędów nie ma.
W naszej wersji często daty dotyczące XIX wieku, czyli 18xx są zmienione na daty z XX wieku czyli 19xx.
I tak pewna osoba zrobiła coś w 1931 roku, a w wyniku czego napisała książkę w 1860 roku....
Nie podejrzewam PWC'a o to, że zrobił błędy, pewnie coś poprzestawiał jakiś zbyt mądry element edytora tekstów, a korekta przespała te błędy.
-
Wojciech Zbigniew Piotrowicz:
IE keszuje laczenie sie ze skryptami ajaksowo.
dodaj dodatkowy parametr, cos na ksztalt:
var iTemp = Math.round(9999);
potem laczac sie ze skryptem dodaj te zmienna do wartosci przesylanych ajaksem.
A może by tak po bożemu? Zmienić GET w POST, albo zmusić serwer do tego by w nagłówkach mówił przeglądarce, że ma nie cache'ować danego zasobu.
-
Jako że nie znoszę Oracla [za wszelkie jego występki przeciwko standardom, błędy w sterownikach JDBC i podobne [np. udziwnione kodowanie znaków, czy nieopisane nigdzie zasady, że jednocześnie nie da się zrobić pewnych rzeczy ;-)]] uprosiłem sobie sprawę i gdy nie podaje gdzieś całej "ścieżki" do bazy to tworzę sobie zawsze 2 wg. schematu:
jdbc:oracle:thin:@//host:port/dbName
jdbc:oracle:thin:@host:port:dbName
gdzie host to host ;-) a dbName to sid lub service name
po czym testuje i jak któraś działa to jej używam.
Btw. widać mam inną wersję sterowników bo u mnie klasa drivera nazywa się: oracle.jdbc.OracleDriver
Spróbuj więc może jdbc:oracle:thin:@//127.0.0.1:1521/ora
-
Ja czytam "po bożemu" czyli wg. kolejności wydań w Polsce, co w dużym stopniu odpowiada kolejności pratchettowskiej. Chyba jedynie terminarze, Eryk i seria o Akwili/Tiffany były wydane w Polsce poza kolejnością.
[tak szczerze to nie wszystko czytam "po bożemu", bo od pewnego momentu zacząłem też czytać oryginały i tu kolejność była z grubsza taka, że pierwsze czytałem to co kupiłem ;-) nawet się kiedyś oszukałem i kupiłem sobie w stanach ichniego Thud'a! choć miałem już brytyjskiego]
Z nowych PTerrych polecam Nation, świetnie się czyta.
-
-
Takie OT ;-)
Marcin Gronowski:
pierwsze wersje FF były nieznośne - wolne i ciągle coś nie działało!
Nie zgodzę się. FF używam od czasów wersji 0.4 gdy nazywał się jeszcze Phoenix [później mu się nazwa na FireBirda zmieniła, a w końcu na Firefox] i już wtedy był bardziej wygodny w użyciu [między innymi szybszy] niż IE :-)
- 1
- 2
- 3
- 4
- Następna »
