Это вопрос ко всем, не только Вам… Неужели все так на Android западают? К тому же надо понимать, что многие мобильные приложения всё равно работают по клиент-серверной архитектуре и на Java у них может быть только клиент.
потому что корпорейт с его Оракловыми базами и фронтендами навевали на меня тоску и раздражали
Вы опять же размышляете только в рамках Java-мира… вот мне и интересно, почему так получается?
Есть же ещё веб, IoT и т.д. Да и та же мобильная разработка, я из статьи не понял как и почему Вы прыгнули с iOS на Android… чисто из-за дизайна?
По заголовку статьи я ожидал, что автор прошёл мимо Java к какому-нибудь другому языку программирования…
Причём, судя по комментариям, автор далеко не одинок в выборе именно Java.
В связи с этим вопрос: чем именно вы руководствуетесь при выборе Java (в целом и Android в частности) для входа в профессию программиста?
Кстати, парень-американец, про которого я в спойлере писал вообще не работал джуниором и после вокршопа сразу устроился на приличную работу.
Это всё про умение себя позиционировать… То, что он, будучи джуниором по факту, устроился на работу мидлом, не делает из него мидла.
Просто мы тут про разные вещи говорим, я про реальные уровни, а Вы про надписи в вакансиях.
К чему было тогда вспоминать Pandas и Scipy, если Вы считаете, что программисты такими вещами не занимаются xD
Если вы придете устраиваться на работу и расскажете как вы в институте делали научные расчеты и больше ничего — вряд ли вас кто-нибудь возьмёт.
Почему же? Я, вполне вероятно, взял бы на Data Scientist. Учитывая, нынешнюю популярность тем Machine Learning и BigData, такому человеку найти работу гораздо проще, чем тому, кто с нуля какой-то воркшоп прошёл.
Не надо думать, что весь мой мир ограничен питоном, я не понаслышке знаком с другими языками.
Судя по Вашим комментариям, в это верится с трудом… Т.е. понятно, что был печальный опыт с PHP лет 7 назад или раньше, ну и JavaScript само собой. Касаемо всего остального, Вы по-моему следуете своему 3-му совету… Хоть и непонятно зачем, я ж Вас не собеседую ;-)
Например, если вы работаете в Enterprise-сфере с применением Java, то совет про смену работы каждые полгода — вряд ли будет полезным и скорее всего навредит.
Конкретно этот совет в принципе спорный… Если проект устраивает, то нет никакого смысла менять работу чаще, чем раз в 3-5 лет. Да и Enterprise Java — это и не про веб-разработку, как правило.
это не значит, что статья только для веб-разработчиков.
Перечитайте статью… помимо Django, там про HTML, JSON, JavaScript, jQuery, AngularJS, HTTP-стек, Mongo, Redis, vagrant, docker, puppet/chef/ansible и т.д… Это всё конечно очень нужно для применения Python в научных расчётах и для анализа данных, не то что фундаментальные знания высшей математики :-)
Если вы считаете, что копипастой моей статьи и заменой отдельных слов на другие можно адаптировать эту статью под другие языки — копируйте и публикуйте.
Зачем? Вас человек спросил, можно ли применить статью к другим языкам. Вы ему ответили, что там очень много Python-специфики, а я, как представитель сообществ других языков, Вас поправил, что статью можно с одинаковым результатом применять практически для любого языка, широко применяемого для веб. Вы зачем-то упорствуете, ссылаясь на незнание других языков, вместо того, чтобы послушать людей (не только я Вам об этом написал), которые знают другие языки. Было б о чём спорить, право слово.
Не "какой-нибудь", а популярный для конкретного языка. Это ведь гуглится за 5 минут.
Я не говорю, что в статье надо было писать как-то по-другому… Просто Python-специфики в ней как раз те самые 5%, о которых Вы же и писали.
все остальные отличаются довольно и для них некоторые пункты статьи будут не актуальными или даже вредными.
Интересно, что из них Вы считаете вредным, скажем, для того же PHP или Go или даже Elixir?
Очевидно, что у каждого языка своя специфика… Но все Ваши пункты об общих вещах, а не о специфике. Да специфики там маленько есть в названиях инструментов, но, как я писал выше, их легко заменить на аналогичные инструменты, без потери смысла остального текста.
P.S. По-большому счёту это Вам же комплимент, что статья получилась достаточно универсальная.
Не вводите людей в заблуждение… Никакой уровень проскочить нельзя. Т.к. они распределяются по объёму практического опыта, а не по кол-ву знакомых слов. А опыт нарабатывается годами применения технологий на практике, поэтому мидлов без, как минимум, 2 лет (чаще 3 лет) практического опыта не бывает. Как говорится, в теории нет разницы между теорией и практикой, а вот на практике всё немного иначе…
Впрочем, кол-во лет само по себе тоже недостаточный критерий… бывает, что джуны никогда не дорастают до мидлов. Вроде и терминов уже на 5 страниц мелким текстом знают, а всё равно самостоятельно выполнить маленькую нетривиальную задачу не в состоянии.
Не согласен, статья полностью посвящена применению Python для веб-программирования. Поэтому легко можно заменить "питонист" на "веб-программист". В статье мало специфичного именно для Python, и при желании всю эту специфику легко можно заменить на аналоги для других языков.
Замены примерно такие:
Python -> название другого ЯП
Django -> популярный full-stack веб-фреймворк под другой ЯП
PyCharm или PyDev -> IDE для другого ЯП или даже универсальный редактор типа Sublime или Atom + плагины под выбранный ЯП
Плюс список стандартных инструментов (virtualenvwrapper, pip, pyenv) тоже надо будет заменить.
В общем, я бы сказал, что в статье достаточно заменить порядка 10 слов, чтобы она стала про Ruby, ну или любой другой ЯП, применяемый для веб-разработки.
Ладно, я Вас понял. Вы считаете, что предлагаемый Вами синтаксис роутов удобно читать… Непонятно только зачем было сравнивать его с Rails, ведь сравнение не в вашу пользу :-)
Ну, обработчик-загрушка и что? Что мешает написать примерно так:
По-моему тут как раз надобность есть, я вон даже не заметил вложенный ресурс в коде, потому что он визуально перегружен. Например, какой смысл identity 9 раз писать?
Причиной такой долгой загрузки рельсов (15-20 сек) может быть большое кол-во мелких гемов.
Или просто размер приложения :-)
Впрочем, на мой взгляд, даже 3-4 секунды — это не очень быстро, хотя это уже приемлемо.
А "очень быстро" — это про миллисекунды.
Если воспользоваться метафорой, то я Вам про BMW X6 рассказываю, а Вы мне упорно доказываете, что Дэу Нексия лучше Лады Веста.
Проблема Go не в том, что сложно написать panic(err), а в том что в нём нет поддержки recovery-политик от слова "совсем". Ну и да, проверять err в каждой штатной ситуации это тоже на порядки неудобнее сопоставления с образцом.
Например, написать вот так (основной happy path отдельно, обработка штатных ошибок отдельно, исключений тут нет) в Go невозможно by design.
with {:ok, res1} <- first_function(),
{:ok, res2} <- second_function(res1),
:ok <- save_result(res2) do
:ok
else
{:error, err} ->
case err.type do
Postgrex.Error ->
# handle err
_ -> ...
end
end
А зачастую бывает удобно именно так. При этом вариант написать аля Go никуда не исчезает для особо разветвлённых happy paths.
Впрочем, насколько я понял, читать про что-то отсутствующее в Go, а тем более изучать, Вы не желаете… Посему опять пытаетесь съехать на хорошо знакомую Вам тему сравнения Дэу с Ладой )))
а вы то к термину "исключение" прицепились и всё запутали.
Ахах, т.е. я виноват, что у вас термин "исключение" при обсуждении Go ассоциируется с control-flow и Java?
Этот подход идеален для любых видов веб-разработки. А что-то другое я на практике редко программирую, поэтому за остальные области судить не буду.
вы уронили программу
Let It Crash в принципе не предполагает ронять программу, скорее наоборот. Практически ничто не способно уронить программу, написанную в таком стиле.
Прочитайте, пожалуйста, маленькую статью на эту тему LetItCrash. И когда будете в ней встречать слово process мысленно переводите его как корутина, а не как процесс уровня OS, так будет понятнее суть. А то получается, что Вы какой-то свой смысл вложили в термин и исходя из него делаете неверные выводы.
Вы будете ронять GUI приложени?
Нет, вычисления будут проводиться в отдельном акторе (корутине, go-рутине, легковесном процессе), если что-то пойдёт не так, то перезапустится конкретный актор, а не всё приложение целиком.
Или веб-сервер, которые получил неверный вход?
Если входные данные невозможно обработать, то упадёт не сервер, а один из воркеров, которые обрабатывают входные данные. После чего он сразу будет перезапущен супервизором и будет готов принимать новые входные данные с чистого листа. Это кардинально отличается от ручного recover, когда вы рискуете не идеально восстановить состояние go-рутины после сбоя.
Это не boilerplate-код, это просто «код».
Ох, мы опять по второму кругу… Просто код — это всё тот же happy path (как в вашем примере открой либо первый файл, либо второй)
Вот тут между нами разница. Я писал на Go, в том числе для production. Вы же тот подход, о котором я пишу, на практике не пробовали, а сравнить пытаетесь на основании субъективных предубеждений. Для меня нет сомнений, что если Вы попробуете Let It Crash, то тоже осознаете, что подход Go примерно так же коряв, как подход Java. Те же грабли, только в профиль.
Вы просто не понимаете Let It Crash, потому что не пробовали его никогда… Во-первых, под процессом там понимается что-то типа горутины. Во-вторых, в Go нет поддержки этого подхода из коробки, попробуйте сначала один из языков, который это наивно поддерживает. Пойдет любой ЯП для Erlang VM.
Это вопрос ко всем, не только Вам… Неужели все так на Android западают? К тому же надо понимать, что многие мобильные приложения всё равно работают по клиент-серверной архитектуре и на Java у них может быть только клиент.
Вы опять же размышляете только в рамках Java-мира… вот мне и интересно, почему так получается?
Есть же ещё веб, IoT и т.д. Да и та же мобильная разработка, я из статьи не понял как и почему Вы прыгнули с iOS на Android… чисто из-за дизайна?
У TeX порог входа повыше, да и он во многом заточен именно под вёрстку книг, а не одной большой страницы неопределенных габаритов.
По заголовку статьи я ожидал, что автор прошёл мимо Java к какому-нибудь другому языку программирования…
Причём, судя по комментариям, автор далеко не одинок в выборе именно Java.
В связи с этим вопрос: чем именно вы руководствуетесь при выборе Java (в целом и Android в частности) для входа в профессию программиста?
Это всё про умение себя позиционировать… То, что он, будучи джуниором по факту, устроился на работу мидлом, не делает из него мидла.
Просто мы тут про разные вещи говорим, я про реальные уровни, а Вы про надписи в вакансиях.
К чему было тогда вспоминать Pandas и Scipy, если Вы считаете, что программисты такими вещами не занимаются xD
Почему же? Я, вполне вероятно, взял бы на Data Scientist. Учитывая, нынешнюю популярность тем Machine Learning и BigData, такому человеку найти работу гораздо проще, чем тому, кто с нуля какой-то воркшоп прошёл.
Судя по Вашим комментариям, в это верится с трудом… Т.е. понятно, что был печальный опыт с PHP лет 7 назад или раньше, ну и JavaScript само собой. Касаемо всего остального, Вы по-моему следуете своему 3-му совету… Хоть и непонятно зачем, я ж Вас не собеседую ;-)
Конкретно этот совет в принципе спорный… Если проект устраивает, то нет никакого смысла менять работу чаще, чем раз в 3-5 лет. Да и Enterprise Java — это и не про веб-разработку, как правило.
Перечитайте статью… помимо Django, там про HTML, JSON, JavaScript, jQuery, AngularJS, HTTP-стек, Mongo, Redis, vagrant, docker, puppet/chef/ansible и т.д… Это всё конечно очень нужно для применения Python в научных расчётах и для анализа данных, не то что фундаментальные знания высшей математики :-)
Зачем? Вас человек спросил, можно ли применить статью к другим языкам. Вы ему ответили, что там очень много Python-специфики, а я, как представитель сообществ других языков, Вас поправил, что статью можно с одинаковым результатом применять практически для любого языка, широко применяемого для веб. Вы зачем-то упорствуете, ссылаясь на незнание других языков, вместо того, чтобы послушать людей (не только я Вам об этом написал), которые знают другие языки. Было б о чём спорить, право слово.
Насколько я понял, автор имеет в виду формат фриланса, т.е. в трудовой книжке никаких записей об этом не будет.
Такое тоже есть, http://tceh.com/edu/ например.
Не "какой-нибудь", а популярный для конкретного языка. Это ведь гуглится за 5 минут.
Я не говорю, что в статье надо было писать как-то по-другому… Просто Python-специфики в ней как раз те самые 5%, о которых Вы же и писали.
Интересно, что из них Вы считаете вредным, скажем, для того же PHP или Go или даже Elixir?
Очевидно, что у каждого языка своя специфика… Но все Ваши пункты об общих вещах, а не о специфике. Да специфики там маленько есть в названиях инструментов, но, как я писал выше, их легко заменить на аналогичные инструменты, без потери смысла остального текста.
P.S. По-большому счёту это Вам же комплимент, что статья получилась достаточно универсальная.
Не вводите людей в заблуждение… Никакой уровень проскочить нельзя. Т.к. они распределяются по объёму практического опыта, а не по кол-ву знакомых слов. А опыт нарабатывается годами применения технологий на практике, поэтому мидлов без, как минимум, 2 лет (чаще 3 лет) практического опыта не бывает. Как говорится, в теории нет разницы между теорией и практикой, а вот на практике всё немного иначе…
Впрочем, кол-во лет само по себе тоже недостаточный критерий… бывает, что джуны никогда не дорастают до мидлов. Вроде и терминов уже на 5 страниц мелким текстом знают, а всё равно самостоятельно выполнить маленькую нетривиальную задачу не в состоянии.
Не согласен, статья полностью посвящена применению Python для веб-программирования. Поэтому легко можно заменить "питонист" на "веб-программист". В статье мало специфичного именно для Python, и при желании всю эту специфику легко можно заменить на аналоги для других языков.
Замены примерно такие:
Python -> название другого ЯП
Django -> популярный full-stack веб-фреймворк под другой ЯП
PyCharm или PyDev -> IDE для другого ЯП или даже универсальный редактор типа Sublime или Atom + плагины под выбранный ЯП
Плюс список стандартных инструментов (virtualenvwrapper, pip, pyenv) тоже надо будет заменить.
В общем, я бы сказал, что в статье достаточно заменить порядка 10 слов, чтобы она стала про Ruby, ну или любой другой ЯП, применяемый для веб-разработки.
Ладно, я Вас понял. Вы считаете, что предлагаемый Вами синтаксис роутов удобно читать… Непонятно только зачем было сравнивать его с Rails, ведь сравнение не в вашу пользу :-)
Ну, обработчик-загрушка и что? Что мешает написать примерно так:
Впрочем ладно, что-то я разошёлся… Через годик освоитесь с макросами, перестанете считать их "тёмной магией" и всё будет чудесно.
По-моему тут как раз надобность есть, я вон даже не заметил вложенный ресурс в коде, потому что он визуально перегружен. Например, какой смысл identity 9 раз писать?
Или просто размер приложения :-)
Впрочем, на мой взгляд, даже 3-4 секунды — это не очень быстро, хотя это уже приемлемо.
А "очень быстро" — это про миллисекунды.
А почему не сделать resources макросом и до конца уж эмулировать роутинг в стиле Rails? Это ж Lisp, тут милое дело DSL создавать.
Кстати, есть поддержка неймспейсов и вложенных ресурсов? Что-то типа:
Шутите? 15-20 секунд — это очень быстро?
Чтобы хоть как-то снизить время ожидания, придумана куча воркэраундов типа Zeus, Spork, Spring.
Если воспользоваться метафорой, то я Вам про BMW X6 рассказываю, а Вы мне упорно доказываете, что Дэу Нексия лучше Лады Веста.
Проблема Go не в том, что сложно написать
panic(err), а в том что в нём нет поддержки recovery-политик от слова "совсем". Ну и да, проверять err в каждой штатной ситуации это тоже на порядки неудобнее сопоставления с образцом.Например, написать вот так (основной happy path отдельно, обработка штатных ошибок отдельно, исключений тут нет) в Go невозможно by design.
А зачастую бывает удобно именно так. При этом вариант написать аля Go никуда не исчезает для особо разветвлённых happy paths.
Впрочем, насколько я понял, читать про что-то отсутствующее в Go, а тем более изучать, Вы не желаете… Посему опять пытаетесь съехать на хорошо знакомую Вам тему сравнения Дэу с Ладой )))
Ахах, т.е. я виноват, что у вас термин "исключение" при обсуждении Go ассоциируется с control-flow и Java?
Этот подход идеален для любых видов веб-разработки. А что-то другое я на практике редко программирую, поэтому за остальные области судить не буду.
Let It Crash в принципе не предполагает ронять программу, скорее наоборот. Практически ничто не способно уронить программу, написанную в таком стиле.
Прочитайте, пожалуйста, маленькую статью на эту тему LetItCrash. И когда будете в ней встречать слово process мысленно переводите его как корутина, а не как процесс уровня OS, так будет понятнее суть. А то получается, что Вы какой-то свой смысл вложили в термин и исходя из него делаете неверные выводы.
Нет, вычисления будут проводиться в отдельном акторе (корутине, go-рутине, легковесном процессе), если что-то пойдёт не так, то перезапустится конкретный актор, а не всё приложение целиком.
Если входные данные невозможно обработать, то упадёт не сервер, а один из воркеров, которые обрабатывают входные данные. После чего он сразу будет перезапущен супервизором и будет готов принимать новые входные данные с чистого листа. Это кардинально отличается от ручного recover, когда вы рискуете не идеально восстановить состояние go-рутины после сбоя.
Ох, мы опять по второму кругу… Просто код — это всё тот же happy path (как в вашем примере открой либо первый файл, либо второй)
А boilerplate-код это:
И ещё recover, сиротливо воткнутый куда-то.
Вот тут между нами разница. Я писал на Go, в том числе для production. Вы же тот подход, о котором я пишу, на практике не пробовали, а сравнить пытаетесь на основании субъективных предубеждений. Для меня нет сомнений, что если Вы попробуете Let It Crash, то тоже осознаете, что подход Go примерно так же коряв, как подход Java. Те же грабли, только в профиль.
Вы просто не понимаете Let It Crash, потому что не пробовали его никогда… Во-первых, под процессом там понимается что-то типа горутины. Во-вторых, в Go нет поддержки этого подхода из коробки, попробуйте сначала один из языков, который это наивно поддерживает. Пойдет любой ЯП для Erlang VM.