0
Пройшло цікаво. Було дещо незвично, але по інтенсивних обговореннях після доповідей склалась думка що таки сподобалось.
Крім .Net UG та Java UG є ще EDGE Lviv — edge-lviv.blogspot.com/
На скільки я в курсі, Діма Малєєв планує в Вересні .Net подію на цілий день.
Також є попередня домовленість на кооперацію принаймні .Net UG та EDGE Lviv щодо заходу на цілий день, але вже з різними технологічними напрямками.
Крім .Net UG та Java UG є ще EDGE Lviv — edge-lviv.blogspot.com/
На скільки я в курсі, Діма Малєєв планує в Вересні .Net подію на цілий день.
Також є попередня домовленість на кооперацію принаймні .Net UG та EDGE Lviv щодо заходу на цілий день, але вже з різними технологічними напрямками.
0
деякі сценарії використання Hadoop підпадають під частину задач parallel computing
і так, 3-4 роки тому я не знав про існування Hadoop :)
і так, 3-4 роки тому я не знав про існування Hadoop :)
0
Я не казав «революція», я казав «радикальне оновлення». Це є різні речі.
Грань між технологією та продуктом є дуже тонка. Наприклад, Amazon Web Services це продукт чи технологія? :)
Але це не важливо, важливо те, що постійно треба бути готовим до змін, так як незалежно від нашого бажання, йде невпинне оновлення чи продуктів, чи технологій.
Подана підбірка технологій не є зрізом «трендових» тем якогось новинного ресурсу для розробників. Це технології які вже зустрічаються, або будуть з'являтись найближчим часом на комерційних проектах.
Наприклад я встиг вже використати половину з них на комерційних проектах. Причому 3-4 роки я не знав про існування цих речей.
Щодо того ж MVP. MVP проявився у всій своїй красі в комбінації з EventBus аж в GWT. Перше велике представлення було на Google IO 2009. Тобто самому шаблону дійсно 21 рік, але тільки недавно він проявився у всій своїй красі та по призначенню.
Грань між технологією та продуктом є дуже тонка. Наприклад, Amazon Web Services це продукт чи технологія? :)
Але це не важливо, важливо те, що постійно треба бути готовим до змін, так як незалежно від нашого бажання, йде невпинне оновлення чи продуктів, чи технологій.
Подана підбірка технологій не є зрізом «трендових» тем якогось новинного ресурсу для розробників. Це технології які вже зустрічаються, або будуть з'являтись найближчим часом на комерційних проектах.
Наприклад я встиг вже використати половину з них на комерційних проектах. Причому 3-4 роки я не знав про існування цих речей.
Щодо того ж MVP. MVP проявився у всій своїй красі в комбінації з EventBus аж в GWT. Перше велике представлення було на Google IO 2009. Тобто самому шаблону дійсно 21 рік, але тільки недавно він проявився у всій своїй красі та по призначенню.
0
декілька напрямків:
server side javascript, platform as a service (azure, cloudfront), nosql mainstream, location based services mainstream, social services development (facebook apps, VK apps), MVP/MVVM, social services integration/mining, HTML5 apps
server side javascript, platform as a service (azure, cloudfront), nosql mainstream, location based services mainstream, social services development (facebook apps, VK apps), MVP/MVVM, social services integration/mining, HTML5 apps
0
разом з ростом аутсорсингу росте якість нашої роботи. тому за ростом прибутків є не стільки кількість, скільки якість. поки буде рости якість, та складність за яку ми можемо братись, доти будуть рости прибутки.
дах — це західна зарплата
дах — це західна зарплата
0
англійську — це обов'язково
про корупцію — думаю таки варто пробувати на особистісному рівні. за день чи за рік мільйони людей не зміниш, але підтримувати мораль і називати корупцію злом — це обов'язково. частина задумається. можливо саме це і підштовхне людину у конкретному випадку для виправлення своєї поведінки
про корупцію — думаю таки варто пробувати на особистісному рівні. за день чи за рік мільйони людей не зміниш, але підтримувати мораль і називати корупцію злом — це обов'язково. частина задумається. можливо саме це і підштовхне людину у конкретному випадку для виправлення своєї поведінки
0
Я бачу декілька факторів які формують правило 80-20
1) Якщо задача пов'язана з іншими людьми, людина очікує що все буде зроблено вчасно. Так як вони працюють разом, а це вселяє хибну довіру.
2) Якщо задача займає більше чим один день, дуже легко помилитись в годинах, так як більшість людей мають різні продуктивності протягом дня, і цілком можливо, що коли людина почне роботу над таском, це буде не її «самий кращий» час. Враховуючи це і то що може бути багато таких тасків більших за один день, на рівному місці може бути відставання, навіть при гарно планованому графіку.
3) Досить часто людина працює над чимось новим, чи неочікуваним. Тобто повна складність задачі проявляється тільки під час виконання. У таких видатках правило 80-20 допоможе подивитись на ситуацію збоку та прийняти рішення, чи варто перепрацьовувати за ці останні 20 відсотків, чи ті 80 що вже є, є достатніми.
Загальні правила естімейшину, це дещо інше чим правило 80-20, тому і техніки інші. Самі простіші з них це множити оцінку часу на певний коефіцієнт в залежності від рівня виконавця. Наприклад для мід девелопера це х2, для сініора х1.5. Тобто реальний час роботи міда для таску на один тиждень буде два тижні.
Звучить сумно, але такі реалії :)
1) Якщо задача пов'язана з іншими людьми, людина очікує що все буде зроблено вчасно. Так як вони працюють разом, а це вселяє хибну довіру.
2) Якщо задача займає більше чим один день, дуже легко помилитись в годинах, так як більшість людей мають різні продуктивності протягом дня, і цілком можливо, що коли людина почне роботу над таском, це буде не її «самий кращий» час. Враховуючи це і то що може бути багато таких тасків більших за один день, на рівному місці може бути відставання, навіть при гарно планованому графіку.
3) Досить часто людина працює над чимось новим, чи неочікуваним. Тобто повна складність задачі проявляється тільки під час виконання. У таких видатках правило 80-20 допоможе подивитись на ситуацію збоку та прийняти рішення, чи варто перепрацьовувати за ці останні 20 відсотків, чи ті 80 що вже є, є достатніми.
Загальні правила естімейшину, це дещо інше чим правило 80-20, тому і техніки інші. Самі простіші з них це множити оцінку часу на певний коефіцієнт в залежності від рівня виконавця. Наприклад для мід девелопера це х2, для сініора х1.5. Тобто реальний час роботи міда для таску на один тиждень буде два тижні.
Звучить сумно, але такі реалії :)
0
це дуже добрі новини, так як тепер буде дві офіційні jdk, що полегшить тестування на швидкодію
0
прикольно!
треба собі прикупити =)
можна купити малу клавіатуру, малу мишку і перехідник :)
треба собі прикупити =)
можна купити малу клавіатуру, малу мишку і перехідник :)
0
цікава підбірка відео, дякую!
0
тобто половина насправді нижче середнього?
0
молодці!
чекаємо з нетерпінням.
чекаємо з нетерпінням.
0
Post release
0
цей туторіал більше орієнтований на XML опис
опис анотаціями дійсно простіший — для цього варто зробити окремий туторіал
опис анотаціями дійсно простіший — для цього варто зробити окремий туторіал
0
Друге відео перезаллю.
zenyk