Вот такая вот у нас профессия — большая часть IT-шных проектов запускается с целью кого-нибудь сократить.
С другой стороны, после внедрения автоматизации эффективность, а значит и прибыль, предприятия повышается, оно расширяется и набирает новых людей. Но — с более высокими требованиями, для работы с более сложной техникой.
Те, кто не может или не хочет учиться, остаются на обочине. В 19 веке в Англии их отправляли на каторгу как бродяг, в 21 веке им светит минимальный паек. Увы, СССР с его правом на труд для каждого "не взлетел".
Странно, что в качестве метрики выбрали именно посещаемость. Имхо, самый важный критерий — сложность, а на втором месте — эффективность. Просто потому, что медленно работающий сайт можно быстро "починить" вливанием денег в железо, в то время как проект, провалившийся из-за недостаточного качества фреймворка/языка/программистов, починке не подлежит.
С другой стороны, очень мало сложных, посещаемых, эффективных проектов начинались именно такими. Как правило, все начинается со стартапов, где требуется сделать что-то работающее за минимальные деньги, а уже потом как-то чинить и переписывать. Если выстрелит.
Поэтому в интернете всегда будет много мнений, на чем надо писать сайт.
Я программировал на бейсике, не умея произносить английские буквы. Для каждого оператора у меня было "название" на основе прочтения латиницы как надписей на русском. Команда "Веер" например.
А подросткам обязательно надо изучать основные алгоритмы и структуры данных, для чего надо дополнительно:
строгую типизацию
ООП
И я, право, не знаю, что подходит лучше, чем древний бейсик и древний паскаль. На каком современном языке программирования можно в 10 строчек нарисовать синее небо, зеленую землю и желтое солнце? Или звездную ночь? А я такие программы набивал с тетрадки в 3 классе, а в 5 писал сам.
"С аккаунта была замечена подозрительная активность, добавьте номер телефона к своему аккаунту". Между "я умудрился засветить пароль, не пользуясь аськой годами" и "мейл.ру вымогает мой номер телефона" я выберу второе. Репутация однако.
Ну как же? ТЗ — это работа, на которую требуется время. Более того, это работа с полезным результатом (который можно отдать другому исполнителю на разработку). Поэтому она должна быть оплачена.
Имеет смысл задуматься и посмотреть на это со стороны бизнеса. Программа нужна для того, чтобы экономить деньги или зарабатывать деньги. Пока нет программы — бизнес терпит убытки. Далее, программистам платят за время. В итоге получается, что программисты напишут программу неизвестного качества, за неизвестное время и за неизвестное количество денег. Аджайл и прочий скрам уменьшают неопределенность, но увеличивают стоимость разработки за счет дополнительного времени, которое тратится на ритуалы.
вконтакте?
Вот такая вот у нас профессия — большая часть IT-шных проектов запускается с целью кого-нибудь сократить.
С другой стороны, после внедрения автоматизации эффективность, а значит и прибыль, предприятия повышается, оно расширяется и набирает новых людей. Но — с более высокими требованиями, для работы с более сложной техникой.
Те, кто не может или не хочет учиться, остаются на обочине. В 19 веке в Англии их отправляли на каторгу как бродяг, в 21 веке им светит минимальный паек. Увы, СССР с его правом на труд для каждого "не взлетел".
http://caniuse.com/#feat=web-app-manifest
Что тут еще можно сказать...
Странно, что в качестве метрики выбрали именно посещаемость. Имхо, самый важный критерий — сложность, а на втором месте — эффективность. Просто потому, что медленно работающий сайт можно быстро "починить" вливанием денег в железо, в то время как проект, провалившийся из-за недостаточного качества фреймворка/языка/программистов, починке не подлежит.
С другой стороны, очень мало сложных, посещаемых, эффективных проектов начинались именно такими. Как правило, все начинается со стартапов, где требуется сделать что-то работающее за минимальные деньги, а уже потом как-то чинить и переписывать. Если выстрелит.
Поэтому в интернете всегда будет много мнений, на чем надо писать сайт.
Я программировал на бейсике, не умея произносить английские буквы. Для каждого оператора у меня было "название" на основе прочтения латиницы как надписей на русском. Команда "Веер" например.
В корне не согласен со статьей… Ну зато у меня конкуренация на рынке труда будет меньше!
По моему мнению, язык программирования для детей должен уметь разговаривать и рисовать, а для этого нужно:
А подросткам обязательно надо изучать основные алгоритмы и структуры данных, для чего надо дополнительно:
И я, право, не знаю, что подходит лучше, чем древний бейсик и древний паскаль. На каком современном языке программирования можно в 10 строчек нарисовать синее небо, зеленую землю и желтое солнце? Или звездную ночь? А я такие программы набивал с тетрадки в 3 классе, а в 5 писал сам.
Спасибо за развернутый комментарий!
Пост очень похож был на рекламный — я до самого конца был уверен, что вы эти книги продаете, а пост сделан для пиара магазина.
Я изучал языки в таком порядке: ZX BASIC — ZX asm — Pascal/x86 asm — C — Java. Никакой деградации не ощущаю.
"С аккаунта была замечена подозрительная активность, добавьте номер телефона к своему аккаунту". Между "я умудрился засветить пароль, не пользуясь аськой годами" и "мейл.ру вымогает мой номер телефона" я выберу второе. Репутация однако.
Я когда-то перешел с аськи на скайп исключительно из-за удобных групповых чатов. Еще — icq2000 была последним вменяемым официальным клиентом.
Ну как же? ТЗ — это работа, на которую требуется время. Более того, это работа с полезным результатом (который можно отдать другому исполнителю на разработку). Поэтому она должна быть оплачена.
очень даже можно, гуглите Арифметическое кодирование)
Я вот после первого абзаца пролистал до комментариев :-)
Имеет смысл задуматься и посмотреть на это со стороны бизнеса. Программа нужна для того, чтобы экономить деньги или зарабатывать деньги. Пока нет программы — бизнес терпит убытки. Далее, программистам платят за время. В итоге получается, что программисты напишут программу неизвестного качества, за неизвестное время и за неизвестное количество денег. Аджайл и прочий скрам уменьшают неопределенность, но увеличивают стоимость разработки за счет дополнительного времени, которое тратится на ритуалы.
Ну и как тут не нервничать? :-)
для протаскивания существует dependency injection. Скаловский подход с cake pattern, синглтонами и имплиситами ошибочен.
Вот чем вам не нравится советский подход к информатике? Сначала играться с бейсиком, потом писать на паскале поиски-сортировки-деревья.
Так хаскель, я надеюсь, не претендует на роль промышленного языка? Или на простоту?
Вот потом этот каждый первый и идет в собственный бложик крыть скалу разными частями тела. За ее сложность.
Можно
Future.sequence(List(v1, v2)).map(_ + _).flatMap(runTask3)Но мы же говорим о промышленном коде, а не олимпиадном, не так ли?