Morgan McKinley opublikowal wczoraj swoj Salary Guide 2014. Oprocz informacji o stawkach, znalazly sie tu tez dane o tym, na jakich pracownikow jest najwieksze zapotrzebowanie.

Notka prasowa:

http://www.siliconrepublic.com/careers/item/35585-high-demand-for-digital-rand

Raport na stronie Morgan McKinley

http://www.morganmckinley.ie/salary-survey

Bezposredni link do PDFa

http://jobs.morganmckinley.com/sites/default/files/3325%20Salary%20Guide%202014%2029.01.14%20Web%20final%20(7.5mb).pdf

#irlandia #praca #emigracja #programowanie #webdev #bazydanych
@000loki: Dublin i niedlugo tez pewnie uk.

A na racu jak masz na przyklad dwa nody to na kazdym sekwencja ma swoj offset.

Node1 seq1 liczy od 1 do 10, potem od 21 do 30, dalej od 41 do 50 i tak dalej

Node2 seq1 liczy od 11 do 20, potem 31 do 40, od 51 do 60 etc.

Dzieki temu nie musza sie synchronizowac co chwila, ale jesli zapytania moga
@msq: powiem Ci, ze fajnie. Dostalem test logiczny taki dość sensowny i bardzo proste zagadnienie z baz (zaprojektowac bazke ktora ogarnia projekty, pracownikow i ich czas pracy) porobic na niej dane selecty i to wszystko.

Test logiczny mial 11 pytan, z czego 10 zrobilem dobrze.

Potem mialem rozmowe na ktorej najwiecej ciekawilo ich jak tuningowalem bazy, a potem juz tylko ogolnie gadka o tym czym sie zajmuje/zajmowalem i czym sie oni
@Cytryndor: kiedys na studiach bylem najlepszy w grupie. A byc moze na roku z Sqla. W pierwszej pracy - jeszcze na studiach jako jedno z pierwszych zadan dostalem raport oparty o sqla. Zrobilem zapytanie w 15 minut. Zadowolony z siebie pokazalem przelozonemu. Ten sie tylko usmiechnal i kazal je odpalic. Po paru godzinach przychodze do niego z info ze nie wiem o co biego bo zapytanie sie nie skonczylo. Tak sie
@Kamileeek: Fajnie by kurde było, żeby kiedyś tak przyszedł do pracy koleś, który by prostu umiał, a nie taki, który się będzie dopiero uczył. A co do zapytania - zgadzam się, zapytanie nie jest trywialne, a to dlatego, że model danych jest konkretnie spieprzony. Model danych ma odpowiadać najpierw na proste pytania: KTO CO ROBI ("ROBI" to opis relacji):

Operator jest

Klient jest

Telefon jest

Operator oferuje usługę

Klient zamawia usługę
Mireczky, możecie pomóc z małym zapytaniem?

Mam bazę danych z przepisami. Zawiera następujące tabele:

przepisy (tutaj jest treśc przepisu)

przepisyskładniki(zawiera dane o tym jaki przepis wymaga jakich składników)

składniki
uzytkownicy (zawiera dane o tym co kto ma w lodówce).

Teraz chciałbym zrobić zapytanie które sprawdzi czy user ma wymagane składniki do danego przepisu.

mam wyciągnięte wszystkie składniki które posiada użytkownik, ale jak daje warunek WHERE id_skladnik IN (tutaj zapytanie wyciagające składniki)
@JareqQ: select ps.skladnikID, su.skladnikID from przepisySkladniki ps left join skladnikiUzytkownika su on su.skladnikID = ps.skladnikID and su.userID = USERID where ps.przepisID = PRZEPISID and (su.skladnikID is null or su.ilosc < ps.ilosc);

jeżeli zwróci ci jakieś wiersze, to użytkownik nie ma wszystkich składników (konkretnie: w przepisie występują składniki, które nie mają odpowiedników w 'spiżarni' lub są w ilości mniejszej niż wymagana)
#bazydanych

Czy klucze (główny i obcy) muszą być tak samo nazwane? Mam taką sytuację:

tabela [przedmiotnowy] z atrybutem idnowy

tabela [przedmiotużywany] z atrybutem idużywany

tabela [sprzedaż] z atrybutem idprzedmiotu

Zakładając, że id
nowy i id_używany się nie dublują, czy mogę robić złączenia [sprzedaż] z obu przedmiotami po identyfikatorach?
@msq: MySQL na szczęście sam tworzy nazwy indeksów - jeśli twórca nie zdecyduje inaczej. Rzeczywiście, jeśli tworzysz je ręcznie, to trzeba mieć jakieś spójne zasady.

W firmie w której pracuję takie standardy były gdy przyszedłem do pracy i takich nawykó nabrałem po prostu :)


Ja już pracowałem w firmach i z jednym i z drugim podejściem (a także z podejściem "mieszanym"). Aliasowanie jest, przynajmniej dla mnie, zdecydowanie przejrzystsze.
@000loki: Ja sie szykowalem w koncu do 1zo-051, zeby docelowo dojsc do 1zo-146, ale w tak zwanym miedzyczasie okazalo sie ze musze troche hive i hadoopa pociagnac i teraz wsiaklem w big data wiec chwilowo moje przygotowania do egzaminu sa zawieszone :)

Wczesniej zdawalem OCE na MySQL developer jeszcze jak bylo w wersji 5
Planuję przepisać swój dogemonitor.com na Node.JS (i Socket.IO). Myślę, że większość potrzebnych danych będę trzymał w pamięci. Jednak potrzeba jest też archiwizowania wszystkich transakcji z giełd do bazy danych. Na chwilę obecną (3 tygodnie pracy serwisu) baza danych ma 650 tys wierszy i waży 100MB.

I rodzi się pytanie. Co może być do takich danych lepsze? Jakiś NoSQL?

#webdev #programowanie #bazydanych #sql
Jak ktos zainteresowany danymi kontakltowymi do rekrutera od ktorego dostalem ponizsza oferte - prosze na pw.

Stawka roczna, w euro.

Role: Senior Operations Engineer – Linux – Monitoring - Scripting

Location: Dublin City Centre

Salary: €55 000- €65 000 (Experience and Seniority Dependant)

Benefits: Pension, Bonus, Health insurance

X-factor: High calibre colleagues- transfer of knowledge culture- 24X7 production environment- new and intelligent technology solutions- employee centric

My client is a market leading
W sumie podpada to pod 3 tagi, więc sorry za spam, ale:

Jeśli w MySQL użyję: UPDATE tabela SET starenetto=netto, netto = 100, brutto = netto * 1,23;

to czy brutto mi się ustawi poprawnie na 123zł, a poprzednie netto zostanie zapamiętane?

W sensie, czy przypisania pól są GWARANTOWANE do wykonywania się od lewej do prawej i te wartości można wykorzystać dalej w jednym zapytaniu, czy wszystkie pola są wczytywane do pamięci
@aaadaaam: generalnie to działa. Na 5.0 i 5.5. Schematy testowe jak wyżej "ustaw netto, wykorzystaj kolumnę do brutto" niby chodzą. "Generalnie" i "niby". Jako jednak, że w dokumentacji jest o magiczne "z reguły", a jest to system finansowy, to chyba nie odważę się puścić tego na większą skalę :)
@RRybak: Będzie dzialało do czasu....

a jest to system finansowy


Ja bym forsował refaktoryzacji aplikacji.

To się robi. Systemy się zmieniają coś co miało być na rok, służy potem wiele lat i pojawia się problem jak tutaj z ceną.