Я подумував бути спікером, але на сайті конференції так і не знайшов де можна подати заявку. Сподіваюся наступного року це буде простіше зробити :-)
Судячи з опису днів .NET народ не бажаний? Чому б це?
Не можна порівнювати парові машини і AI. Думаю професія програмера буде останньою. Після автоматизації програмування у нас будуть машини, які матимуть штучну силу і штучний інтелект. Нам нічого не залишатиметься як усім стати бізнесменами і очолювати компанії, в яких працюватимуть роботи. Кожен по суті буде королем зі слугами і робітниками. Кожен буде насолоджуватися життям і займатися чим заманеться. Безробіття? Так, але це буде безробіття усім забезпеченої людини, типу людини, що успадкувала мільярд баксів. Я лише за таке безробіття :-).
Будь ласка :-) Бажаю успіхів!
я не особо мастак в саморекламе и составлении резюме.— це на мою думку корень проблеми. Не розвивати ці навички, а вивчати ще щось, на моє глибоке переконання, є основною помилкою. Ви гадаєте в компаніях тестери сидять, які усе знають? Та нічого подібного. Думаєте на робочому місці буде потрібно усе те, що вивчили? Лише 20%. Кілька порад:
Дякую, судячи з назви цікава книжка, сподіваюся вона зможе пролити світло на те, що справді економічно вигідно робити на проектах, а що ні :-)
О, цікаво, я не знав про чувака. Дякую!
Як на мене чудова мотиваційна стаття! Навчання як прихована форма споживання та страху щось створювати — дуже цікаве спостереження, ніколи так про це не думав раніше. Тепер щоразу сідаючи за черговий цікавий курс — задумуватимусь :-)
Ну трохи висловився не точно, вони то є, але достовірність їх результатів — сумнівна. Достовірність — це повторюваність експериментів. А там як завжди, взяли купку приятелів і попросили оцінити, як вам здається, TDD зменшило кількість багів? Я сам цим в універі займався і тони цих статей перерив. В дисертації було треба експерементальну частину (дісєр був про ООП дизайн), ну дик я туди case study закинув, бо формально це empirical research method, але чи можна цьому довіряти і узагальнувати? Сумніваюся :-)
Справді, гарне пояснення, але нажаль це лише правдоподібне припущення. Ми не можемо заявити що це так і спонукати людей робити TDD. А якщо це не так? А якщо design-by-contract, наприклад, теж змушує краще продумувати код але при цьому контракти не так напряжно підтримувати. Ех, ми мало насправді знаємо. Якщо цікаво, на цю тему є дуже класний епізод подкасту www.functionalgeekery.com/...
Немає емпіричних наукових досліджень, які б доводили ефективність TDD. Якби вони були, усіх би змусили це робити для заощадження коштів. Тест відбиває свою ціну виключно коли падає через реальну помилку. В моїй практиці таке трапляється украй рідко, тобто тести у моїх проектах це самі лише витрати. Так, я припускаю, що не тямлю їх писати :-). У нашій галузі взагалі нічого не піддається незалежним експерементам, тому кожен кому не лінь ліпить свої методології/технології, а потім люди сперечаються довго і нудно без реальних аргументів підкріплених hard data. Саме тому це називають релігійними війнами.
Можливо ваша правда. Усі інші «поліморфізми» не дають головного: dependency inversion. Тому може й не варто розглядати їх як поліморфізм.
Хех, ваша правда, треба було уточнити що я мав на увазі саме назву, не сигнатуру. Якщо брати сигнатуру то і динамічний поліморфізм — не поліморфізм :-). Адже x.f(y) просто синтаксична зручнсть, могло б бути і так: f(x,y). Тобто належність методу до іншого класу майже те саме що метод мав би перший параметр іншого типу (іншу сигнатуру). Для того щоб поліморфізм реалізувати методи таки мають чимось відрізнятися :-).
Поліморфність=багатоформеність. Тобто якась сутність може приймати одну чи іншу форму. Тобто сутність — це метод, а форма його — це реалізація. Будь які суперечки виникають через брак дефініцій :-). Такщо перевантаження методу — поліморфізм статичний, тобто рішення про те яку форму прийме метод приймається підчас компіляції. Наприклад лябда функція передана до іншої як параметр — теж форма поліморфізму. Можна піти далі і назвати змінну поліморфною сутністю. Але усе це цікаво з точки зору академічних вправ. Практичного значення у таки питаннях мало...
TypeScript?
Що ж, напевне Ваша правда, я на таких штуках не дуже знаюся. Просто пригадався IBM Smart Planet лозунг і їхні намагання робити розумні міста, от і припустив, що можливо уже розвязана ця задача. В кожному разі навряд чи це по зубам і до вподоби хлопцеві, що задає запитання :-).
Думаю що планувальник такий уже є. Магістерська повинна відповісти на якесь наукве запитання, містити нове знання. Те що юнак багато працюватиме нед програмою дасть йому цінний досвід, але не дасть диплома :-). Звісно, залежить ще від вуза.
Хм, але ж Clojure динамічно типізований :-)