Pull to refresh
37
Karma
0.4
Rating

Пользователь

Из джуна в мидла: рекомендации, как справиться с проблемами роста

А что если человек уже достаточно "вырос"? Мне на одном собеседовании задавали вопросы:

"Что тебя не устраивает на текущей работе?" - меня это поставило в тупик, потому что если что-то не устраивает, то это повод попробовать это изменить самому или поговорить с коллегам о проблеме, а не менять работу, и вообще это вы меня позвали на собеседование, а не я жаждал к вам сбежать от каких-то проблем.

"В чем хотелось бы развиваться?" - я считаю, что в своей области я знаю больше чем кто-либо на этой планете (возможно я переоцениваю себя самую малость :)) и мне хочется просто реализовать этот опыт, делать какие-то клевые продукты. У меня совершенно точно никогда не было потребности в том, чтобы кто-то в компании занимался моим развитием. Мне вообще это на столько чуждо и непонятно. Если у меня возникает потребность в развитии, то я просто начинаю что-то читать, проходить курсы, делать какие-то проектики, предлагать на работе сделать какую-нибудь клевую фичу.

Что-то типа "Какой уровень у ваших коллег сейчас? У нас очень хорошие специалисты. Наверное хорошо работать в команде профессионалов? Можно развиваться и т.п." - в моём понимании это вообще лютый патернализм. Менять работу, когда на текущей работе тебя всему научили и искать новую работу, чтобы тебя продолжили учить там - такое себе. Хотя тут наверное нужен баланс, конечно нужно учиться у других, но, блин, иногда наверное нужно 1) самому делиться какими-то знаниями 2) или попробовать применить их для создания чего-то.

У меня было ощущение полного кринжа, и что мы с разных планет с челами из той компании. Они задали кучу вопросов, которые наверное очень важны с их точки зрения для принятия решения о смене работы и всё это очень важно с точки зрения "любого ИТ специалиста". При этом, чтобы они что-то рассказали о сути проектов, которыми они занимаются (на мой взгляд это самое важное), нужно пройти ещё кучу собеседований. У меня сложилось впечатление, что они как-раз ищут людей, которые мечтают о "планомерном и беспроблемном росте", которому посвящена эта статья, и ничего другое их не интересует.

До этого все собеседования у меня были абсолютно другими. Мы обсуждали какие-то проекты, и сразу становилось понятно на сколько сильный взаимный интерес.

Планомерный и беспроблемный рост — мечта любого IT-специалиста.

Ощущение, что в ИТ это возводится в аксиому. Некоторым людям нужна просто самореализация, а не бесконечный рост и развитие как самоцель.

Настройка ESLint для чистого кода в проектах на Vue

Если речь об импорте в JS/TS коде, то можно так:

"quotes": ["error", "single", { "avoidEscape": true }]

Вам скорее всего нужен не Сеньор

Согласен. В случае с React наверное пример был корректный. Можно использовать JSX, а можно то же самое написать на JavaScript/TypeScript.

Для Spring, да, разными способами можно описать только конфигурацию приложения. А реализация всего этого всё равно пишется на ЯП общего назначения. Хотя если посмотреть на какой-нибудь Spring Cloud Gateway, то там в конфигах можно описывать уже достаточно сложные правила и может быть даже удобнее чем в коде.

Вам скорее всего нужен не Сеньор

Кодогенерация это ад в поддержке (ни кто не может сделать нормально с первого раза), поскольку нужно знать не только целевой язык, но и логику работы кодогенератора, и учитывать как изменение скажется на всей массе проектов, которые могут не быть под вашем контролем.

Другой вариант - интерпретация, но это может оказаться ещё большим адом, потому что фиг его знает что там в рантайме происходит, пока не запустишь не узнаешь. А в сгенеренный код можно хотя бы посмотреть.

В целом, да, конечно это ад. Когда Gradle или Maven проект не собирается, попробуй пойми что там внутри происходит. Или, например, SQL запросы тормозят и нужно смотреть планы их выполнения. С GitLab CI/CD я недавно намучился, прочитал тонны документации, pipeline нормально начал работать только после 150 запуска. В докере иногда загадочные вещи происходят.

Какая альтернатива-то? DSL и так используются везде, это данность. Отказаться от них и писать всё на языках программирования общего назначения? Но и в их компиляторах/интерпретаторах могут быть баги. Перейти на ассемблер?

Что делать с типовым boilerplate кодом? Мне лень даже копипастить один и тот же код, я скорее напишу какой-нибудь генератор, который это будет делать за меня.

Кодогенераторы бывают очень разные. Например, у меня транслятор из OCL в Java занимал 2000 строк. Транслятор из Xtext (BNF-подобный язык) в JavaScript занимал строк 200. Это достаточно простой код, который легко сопровождается. Я сталкивался и со сложными кодогенераторами, например, в SCADE один из кодогенераторов был написан на Tcl, проще было его с нуля переписать, чем разбираться. Но я не согласен с тем, что кодогенераторы это обязательно что-то очень сложное, что разрабатывается годами, занимает сотни тысяч строк кода.

На этом уровне сложно решать вопросы версионирования и слияния. Это все мега удобно для проектирования, когда у вас один архитектор, десяток-другой сущностей и нужно показать определенные аспекты. Когда их становится больше, то диаграммы превращаются в месиво.

На прошлом проекте в модели данных у нас были тысячи сущностей, сотни процессов. Десятки аналитиков в разных компаниях из разных стран, создающие эти модели. На текущем проекте больший акцент на процессах, их десятки тысяч, сотни моделировщиков. Со слиянием, да, есть сложности. Есть инструменты типа EMF Compare, EMF DiffMerge, ... которые позволяют это делать. Но на практике проще и правильнее разделить зоны ответственности, чтобы потребности в слиянии изменений не возникало вообще.

Короче я не против DSL как идеи, и в определенных задачах в них есть смысл. Но это ни разу не замена ЯП общего назначения.

Конечно это не замена, но я не вижу какой-то принципиальной пропасти между DSL и ЯП общего назначения. Например, мне нужно реализовать какого-нибудь поискового робота. Я могу описать для него конфиг на YAML:

description: News parser
crawl:
  document: http://some-news.example.com
  interval: 1m
  article:
  	path: html/body/div.article
	  title: h1.title
    body: div.content
  	publicationDate:
    	path: span.date
    	format: YYYY-mm-dd

В соответствии с этим конфигом робот может раз в минуту с указанного адреса скачивать HTML-страницу, находить на ней теги div с классом article, в каждом из них находить заголовок, содержание и дату новости.

Могу для того же самого запилить DSL:

define crawler('News parser') {
  crawl('http://some-news.example.com') {
    interva = 1m
    for (`html/body/div.article`) {
      add() {
        title = `h1.title`
        body = `div.content`
        publicationDate = date(`span.date`, 'YYYY-mm-dd')
      }
    }
  }
}

Могу описать примерно то же самое на Java (псевдокод):

public class NewsCrawler implement ICrawler {
  public String getDescription() { retrun "News crawler"; }
  public int getInterval() { return 60; }
  public void run() {
    Document page = PageService.getPage("http://some-news.example.com");
    for (Node article : page.get("html/body/div.article")) {
      ArticleService.add(
        article.get("h1.title"),
        article.get("div.content"),
        article.get(parseDate("span.date", "YYYY-mm-dd")));
    }
  }
}

Могу сделать то же самое, но с аннотациями и Fluent API:

@Crawler("News crawler")
public class NewsCrawler {
  @Crawl(interval = 60)
  public ArticleProvider run() {
    return Document.get("http://some-news.example.com")
      .articles("html/body/div.article")
      	.title("h1.title")
      	.body("div.content")
      	.publicationDate("span.date", "YYYY-mm-dd");
    }
  }
}

Я не вижу принципиальной разницы между всеми этими вариантами. Есть определенная предметная область "Парсинг сайтов". В ней есть свой набор базовых понятий: поисковый робот, документ, который парсится, материалы в этом документе, у которых есть заголовок, содержимое и дата.

Допустим у нас контора, которая пилит такие парсеры сайтов. На начальном этапе каждый пилит как хочет. Затем мы определяем структуру типового парсера, создаём какой-нибудь интерфейс парсера с тремя методами getDescription(), getInterval(), run(), а внутри run() можно писать что угодно. Затем мы пишем какие-нибудь рекомендации по содержимому метода run() типа для получения страницы желательно использовать такой-то класс, а для парсинга HTML такой-то. Затем мы можем реализовать типовые методы для получения страницы, для извлечения из неё материала и т.д. И уже на этом этапе мы создали не что иное как embedded DSL!

Если мы используем какой-нибудь Lisp, то можем пойти немного дальше и определить для нашего DSL более подходящий синтаксис, чем например в Java.

Можем пойти ещё дальше и разработать полностью свой синтаксис для нашего для DSL (например, с помощью Xtext, он практически даром даёт парсер, текстовый редактор с подстветкой синтаксиса и автодополнением). Можем не заморачивать со своим синтаксисом, а использовать тот же YAML.

А затем можем написать либо интерпретатор для этого DSL или этих YAML конфигов, либо транслятор в Java код или ещё во что-то. Причем результирующий код может выглядеть ровно так же как в примерах выше, это не обязан быть какой-то лютый нечитаемый треш.

Я не топлю за то, что абсолютно всегда нужно делать свой DSL с каким-то своим синтаксисом. Я говорю о том, что к разработке любого софта можно относиться как к созданию DSL, т.е. выделить в приложении какие-то осмысленные области, для каждой области определить набор базовых понятий и конструкций. А какой при этом у этих DSL будет синтаксис (какой-то кастомный, YAML, или это будет просто eDSL в Java) - вообще пофиг, что удобнее, то и нужно использовать.

Вам скорее всего нужен не Сеньор

С одной стороны, да, конечно! И есть мнение, что это чуть ли не единственный правильный подход к программированию. Когда-то очень давно прочитал эту статью и она запала мне в душу. По хорошему разработка любого приложения - это разработка своего DSL.

1) Это может быть прямо реальный DSL со своим синтаксисом. При этом синтаксис может быть текстовым (SQL, HTML, CSS, XML, XSLT, XPath, Gradle, Make, JSON, YAML, DOT, PlantUML, Docker, ...) или графическим (BPMN, UML, диаграммы SSIS, ...). А может быть и таким, и таким как у SysML v2. Разработчики постоянно пользуются такими языками. Постоянно появляются новые языки. Они могут быть разной степени сложности. Но если стоимость разработки какого-нибудь простого DSL - пару дней, а время изучения - пару часов, то что в этом плохого? Если это какой-то безумно сложный DSL, который нужно изучать годы и потом эти знания нигде не пригодятся, то наверное это просто не самый удачный язык. Не все DSL похожи на 1С.

2) Может быть DSL, встроенный в другой язык. Например, JavaDoc, LINQ, JSX.

3) Может быть DSL на базе языка с макросами (Lisp) или расширяемым синтаксисом (Isabelle). Тут создание своих своих языков - это просто обычный подход к разработке, с этого всё начинается.

4) Может быть DSL на базе JSON, XML, YAML в виде конфигурационных файлов. Например, GitLab CI/CD, Docker Compose, Ansible, Spring, ...

5) DSL в виде аннотаций. Тот же Spring, UML-профили.

6) Наконец, если все эти кастомные синтаксисы, конфиги и аннотации не для нас, мы просто пишем код на ЯП и всё, то даже в этом случае хорошее приложение состоит из набора микрофреймвоков или наборов типовых компонентов. Например, набор своих или чужих React-компонентов, из которых мы собираем UI. Набор компонентов для обработки каких-нибудь данных, рассылки уведомлений и т.д. Главная идея, что есть какая-то узкая область, например, UI приложения. Этот UI строит из какого ограниченного набора компонентов. А будет UI собираться в коде, описываться на YAML, рисоваться в виде диаграммки или текстом на специальном DSL, ... - вообще пофиг, это уже детали.

Многие фреймвоки реализуют сразу несколько вариантов из перечисленных выше. Например, в Spring одно и то же можно сделать вариантами 4, 5 и 6. Аналогично в Swagger. В React - варианты 2 и 6.

В общем, ещё раз подытожу идею, на мой взгляд, разработка любого приложения - это разработка своего DSL одним или сразу несколькими способами описанными выше. Я думаю, что это нормальный и правильный подход к разработке, когда программист смотрит на приложение с этой точки зрения. В противном случае код превращается в какую-то кашу с файлами на тыщи строк, с классами с десятками приватных полей и методов, которые через эти поля обмениваются какими-то данными и нужно часами дебажить этот код и рисовать на листе бумаги схему его работы, чтобы понять что там вообще происходит. Или если в приложении прямо очень много однотипного boilerplate кода, многие задачи решаются копипастой, куча рутинных задач, то возможно настало время как-то обобщить этот код, сделать свой микрофреймвок, вынести что-то в конфиги или даже сделать свой DSL. Я не то, что не вижу в этом никакой проблемы, а наоборот хороший сеньор должен мыслить такими категориями ещё до того, как рутина в принципе появилась.

С другой стороны, мы никакой собственный язык программирования не придумывали, а взяли готовый. Хотя это не язык программирования, а язык спецификации. Это тоже отдельная тема, я не хочу писать тут ещё столько же текста, пора уже сворачивать этот поток графоманства ) В 90-е высказывались идеи, что на UML можно нарисовать несколько квадратиков, по которым можно сгенерить любое приложение (веб-сайт, компьютерную игру, систему управления атомным реактором), а языки программирования и программисты не нужны вообще. По каким-то "неведомым" причинам идея оказалась несостоятельной :) И с тех пор бытует мнение, что вообще все эти квадратики со стрелочками, текстовые DSL и т.п. не нужны, потому что они не могут заменить языки программирования общего назначения. DSL абсолютное зло, не нужно использовать их нигде и никогда. Но сейчас как-то незаметно DSL стали использоваться практически везде (выше много примеров), а многие разработчики даже не осознают того, что какие-нибудь JavaDoc, Docker, GitLab CI/CD, LINQ, Swagger, Gradle и т.п. - это на самом деле DSL, языки, которые позволяют специфицировать на более высоком уровне абстракции что нужно сделать, чем это делается на ЯП общего назначения.

Безусловно здесь можно впасть в крайность, начать создавать какие-то безумные абстракции над абстракциями, создавать какие-то свои сложнейшие языки, в которых никто никогда не разберется. Поэтому первое что нужно сделать - это посмотреть не создавал ли кто-то такой язык уже до тебя. Например, в нашей предметной области (разработка инструментов моделирования) большая часть DSL уже придумана консорциумом Object Management Group. Тот же OCL для описания правил валидации или запросов к объектным моделям. QVT для преобразования моделей в модели, M2T для преобразования моделей в текстовое представление. MOF для описания языков моделирования. И т.д. Я видел много примеров, когда вместо специального DSL, придуманного умными людьми в серьезных компаниях, используют какие-нибудь VBA, Lua, JavaScript, C# и т.п., мотивируя это тем, что на hh.ru резюме JavaScript разработчиков дофига, а людей со знанием QVT нет вообще. Но в итоге получается печаль печальная, потому что JavaScript не предназначен, например, для преобразования моделей. На нём можно это сделать, но нет никакой гарантии, что в итоге не получится неподдерживаемый лапшакод. Потому что практически все JavaScript разработчики, разместившие своё резюме на hh, занимались совершенно другими задачами (фронтом или бэком), а не преобразованием UML моделей в BPMN модели и не реализацией какого-нибудь имитационного моделирования. Чё-то меня прямо прорвало, извиняюсь за этот поток )

Если подытожить весь этот поток:

1) Я думаю, что разработка своего DSL - это единственно правильный способ создания приложений.

2) Реализованы эти DSL могут быть совершенно разными способами: от диаграммы с квадратиками и стрелочками до микрофреймвока. Принципиальной разницы между ними я вообще не вижу, это детали реализации, какой способ удобнее, тот можно и использовать.

3) Каждый язык должен использоваться для своих задач. Если в коде много boilerplate кода и копипасты, возможно удобнее будет использовать какой-то более высокоуровневый язык.

4) Разные DSL используются практически повсеместно, постоянно создаются новые. Некоторые удачные, некоторые не очень удачные. Но это данность. Многие разработчики думаю, что используют только один ЯП, хотя реально они используют десятки языков, просто не осознают этого.

5) Безусловно есть неудачные примеры очень сложных и узкоспециализированных DSL или когда в приложении накручивают микрофреймвок над микрофреймвоком и в этом невозможно ничего понять. Но это не значит, что сам подход неправильный.

Блин, я никак не могу закончить это сообщение :) На самом деле после всего этого опуса до меня дошло, что я просто являюсь адептом языко-ориенированного программирования и расширяю его на всё программирование вообще. Т.е. в моём понимании все разработчики на самом деле используют ЯОП, просто в разной степени осознают это.

Вам скорее всего нужен не Сеньор

На нашем проекте разобраться в требованиях - вообще не проблема, гораздо сложнее найти людей с опытом в этой области или без опыта, но кому было бы интересно этим заниматься.

Предметная область - разработка инструментов моделирования, анализа моделей, кодогенераторов и т.п. Вполне естественно, что с автоматизацией рутины сложностей нет, т.к. это одно из назначений самого продукта :) Поэтому джуны, которые закрывают типовые задачи по инструкции, не нужны, такие задачи (типа добавления новой формочки, поля, правил валидации, добавления новой нотации моделирования в инструмент, добавления отчета, написания boilerplate кода) уже автоматизированы, или могут быть автоматизированы, или делаются самим заказчиком без участия разработчиков. По сути мы делаем конструктор, который сами же и используем в разработке.

На мой взгляд многие задачи в ИТ проходят через такие стадии:

1) Сначала задача исследовательская, видны только какие-то первые шаги для её решения, как она будет реализована в деталях неизвестно. Для таких задач джуны бесполезны. Они или в принципе не сделают её ни за какое время, или будут делать в 10-50 раз дольше сеньора, или сделают что-то не то.

2) Затем задача тщательно документируется, становится типовой. Остается прочитать разные внутренние руководства по решению таких задач, по оформлению кода и т.п. Для таких задач, да, джуны вполне подходят.

3) Затем задача постепенно автоматизируется. Появляются какие-нибудь скрипты, кодогенераторы, движки с типовыми компонентами. Джун вряд ли сможет разработать что-то такое, но может использовать. Например, сгенерить boilerplate код и что-то ещё дописать. Или взять готовый компонент и задать параметры.

4) Наконец все эти инструменты внутренней автоматизации становятся отдельным продуктом, выходят на рынок и используются повсеместно, задача полностью автоматизирована. Начиная от каких-то внутренних задач. Например, оформление кода, поиск типовых ошибок могут быть автоматизированы с помощью SonarLint, Checkstyle, ESLint - для этой рутины уже не нужен ни джун, ни синьор. Генерация документации по коду. Или при разработке учетных систем, систем документооборота можно делать всё с нуля, а можно взять движок типа DevExpress XAF, или разработать свой такой движок. Тогда большая часть работы будет заключаться а) в описании схемы данных, описании формочек в виде модели (в основном это аналитическая работа, с которой синьор справится быстрее джуна) или б) в реализации сложных вещей, выходящих за рамки готового движка (с этим сеньор тоже справится лучше). В разработке инструментов моделирования я видел примеры, когда люди тратят очень много ресурсов, делая многие вещи с нуля и вручную, вместо того, чтобы взять готовый движок, использовать правильные технологии и сократить время разработки раз в 10.

Я сходу не могу придумать задачи в ИТ, которые невозможно довести до 4-ой стадии. Наверное часто это не делают по каким-то организационным причинам, проще нанять десяток синьоров и сотню джунов. Синьоры будут заниматься сложными задачами и писать инструкции, а джуны по этим инструкциям будут решать типовые задачи.

Хотя, блин, я всё-таки уверен, что сеньору лень заниматься рутиной и он будет искать варианты автоматизации и в итоге сделает задачу быстрее джуна. Например, у нас была такая задача. Есть структуры таможенных и других документов, для них описаны правила заполнения на русском языке. Нужно реализовать систему, которая будет проверять документы на соответствие этим правилам. Типов документов сотни. Правил заполнения для каждого от сотен до тысячи. Самый очевидный вариант решения следующий. Аналитики вникают в эти правила, пишут постановки разработчикам, разработчики реализуют всё в коде, покрывают тестами, тестировщики тестируют вручную. Отличный проект на сотню-другую человеколет, и для джунов работы полно. У нас не было столько джунов, поэтому мы пошли следующим путём. Правила описываются на формальном языке (что-то типа предикатной логики), а всё остальное генерится автоматически. Нужно несколько синьоров, которые реализуют этот транслятор из формального языка спецификации правил в валидаторы документов, а джуны не нужны вообще. Хотя даже при этом всё равно находилась какая-то рутинная работа, которую в принципе можно было бы дать джунам, например, перевод правил с русского языка на формальный. Но у джуна перевод тысячи правил займет неделю непрерывной механической работы. Мне это занятие надоело уже через несколько минут, я потратил день чтобы сделать табличку в Excel с формулами, которые делают это автоматически для большинства правил, а в сложных случаях можно дописать уже вручную.

На мой взгляд, даже если задача совершенно типовая и простая всё равно синьор справится с ней быстрее, потому что он будет искать какие-то варианты автоматизации рутины.

Вам скорее всего нужен не Сеньор

В любом проекте есть уйма типовой работы, с которой может справиться даже новичок.

У нас, например, такой работы очень мало. Рутинные задачи делаются один раз, второй, а в третий раз делать то же самое становится лень и задача автоматизируется. Минус в том, что для джунов нет работы, через которую они могли бы погружаться в проект. Даже если человек в чем-то разобрался, то скорее всего делать ещё раз то же самое по аналогии ему уже не придется, а будет снова задача, в которой придется что-то исследовать, искать варианты решения.

Даже если возникают какие-то типовые задачи, то синьор условно сделает их несколько штук в день, а джун будет одну задачу делать неделю.

Почему МойОфис Таблицы это неудобно и не для всех

Я не наезжаю на LibreOffice Calc. Лично меня смущают эти моменты:

1) Нет таблиц как в Excel (Вставка -> Таблица), не сводных, а обычных. Но, в принципе, это вопрос привычки, вместо них можно делать именованные диапазоны или каждую таблицу выносить на отдельный лист.

2) Сводные таблицы очень непривычные. Непонятно можно ли в одном столбце отображать разные поля (типа Отдел -> Год -> Месяц), чтобы их можно было сворачивать/разворачивать. Я активно пользовался сводными таблицами в Excel, в т.ч. подключенными к OLAP. В LibreOffice Calc всё это выглядит очень урезанно. Возможно большинству людей это не нужно или я не научился пользоваться.

3) Нет полной совместимости с Excel. Не могу нормально открыть свои файлы (во многом из-за пункта 1). Нет гарантии, что мои файлы, сделанные в LibreOffice Calc, нормально откроются в Excel.

4) Непривычный интерфейс после Excel.

5) Многие вещи в Excel и аналогах делаются через магические формулы. Самая безобидная из которых СУММПРОИЗВ. Часто в формулах накручивается такое, что нормальный человек не поймет что всё это значит. Круто, что такое в принципе можно делать, но вопрос в последующей читабельности формул. Отдельная история функции для массивов. Более сложные вещи пишутся на ужасном VBA, которым я старался никогда не пользоваться. Для более сложных вычислений использовал https://excel-dna.net/ В Excel и аналогах можно делать крутейшие вещи, но, блин, в NumPy, Pandas, ... всё это делается на столько проще, понятней и естественней.

В целом всё это достаточно субъективные доводы. Для многих пользователей все эти проблемы могут быть вообще не актуальны. Мой посыл был наверное в том, что есть два подхода к работе с данными: как в Excel и как в Pandas. Лично для меня оптимальный вариант - это видимо гибрид обоих подходов. В этом случае было бы пофиг на пункты 1-4, эта штука была бы на порядок лучше Excel.

Почему МойОфис Таблицы это неудобно и не для всех

В LibreOffice Calc нет таблиц. В MS Excel это "Вставка -> Таблица". По смыслу таблицы похожи на именованные диапазоны и можно было бы использовать их. Или делать для каждой таблицы отдельный лист. Но по-моему это не так удобно и для меня это прямо киллер-фича. Здесь или здесь люди разделились на две группы. Одни пишут, что это чуть ли не самая важная вещь в Excel (как я), другие - вообще недоумевают что это и зачем, есть же именованные диапазоны. Ещё сводные таблицы в LibreOffice Calc как-то не так работают.

Я не могу нормально работать с файлами, которые создавал в Excel. И не могу их как-то переделать, чтобы они нормально работали в Calc. Например, у меня есть статистика по проекту из Jira. В ней большая таблица со списком задач. Я тупо делал выгрузку из Jira и вставлял записи в конец этой таблицы. В Calc почему-то нельзя это просто взять и сделать, не размножаются ячейки с формулами для новых строк. Пытаешься сделать это вручную - вместо результатов вычисления начиная с какой-то строки выводятся ошибки и абсолютно невозможно понять почему, вроде и данные, и формулы аналогичные.

Если добавить к этому ещё непривычный интерфейс, когда практически каждую операцию нужно гуглить, то мне было быстрее просто плюнуть на всё это и переписать на питоне.

Почему МойОфис Таблицы это неудобно и не для всех

Я думал WPS Office преимущественно для мобильных устройств. Посмотрел, он достаточно клевый. В отличие от LibreOffice Calc в нём работают таблицы и интерфейс привычный. Спасибо! Хотя всё равно ощущение, что все эти варианты далеки от идеала. И в MS Excel некоторые вещи делались через костыли, а тут ещё добавляются проблемы с совместимостью. Лично у меня ощущение разочарования от Excel и аналогов, для меня наверное для многих задач проще использовать CSV + Jupyter.

Почему МойОфис Таблицы это неудобно и не для всех

Лично я активно пользовался в Excel обычными таблицами и сводными. Чего я только не делал: трекер задач и систему управления проектами, редактирование схем данных с их версионированием и генерацией SQL запросов, какие-то системы поддержки принятия решений, мини статистические пакеты.

В LibreOffice Calc таблицы практически не работают, плюс очень непривычный интерфейс. В МойОфис на первый взгляд всё посимпатичней. Но один фиг это всё какое-то мучение. Вместо Excel сейчас использую Python, Jupyter, VS Code, Pandas, Matplotlib и т.п.

На мой взгляд пытаться на минималках повторить другой инструмент - это тупиковый путь. Прикрутили бы к тому же Jupyter или VS Code удобный UI для редактирования табличек была бы отличная система на уровень выше Excel, а так какие-то суррогаты получаются.

Некомпетентные компетенции

Почему наука и философия вообще должны противоречить друг другу? Есть много вопросов типа в чем смысл жизни? Существует ли физический мир, другие люди и т.п. или всё вокруг плод нашего воображения? Есть ли у людей свобода выбора, чем вообще сознание людей отличается от сознания андроидов из сериала Мир дикого запада? Все эти вопросы выходят за рамки науки, а ученые, которые пытаются на них отвечать - это лжеученые. Другое дело философия, она позволяет думать на любые темы. Часть из этих рассуждений в итоге окажутся ошибочными, бессмысленными, тупиковыми. Другая часть в итоге ляжет в основу каких-то новых научных дисциплин или теорий.

Так было на протяжении всей истории. Атомизм, логика, всякие принципы, на которых основана современная наука (типа фальсифицируемости, эмпиризма) и т.п. - всё это изначально осмысливалось философами и только потом становилось наукой. Можно ли заниматься наукой не заморачиваясь с философией. Ну, формально нет ) Потому что иначе не сдать кандидатский минимум. С другой стороны конечно можно попробовать его сдать и сразу забыть, но не факт, что это получится.

У каждой научной дисциплины есть определенная область применения. Существуют ли какие-то темы, которые выходят за рамки всех существующих на данный момент научных дисциплин? Наверное, да, и таких областей дофига. Познаваем ли в принципе окружающий мир, неважно с помощью науки или ещё каких-то методов познания, которые будут использоваться через сто тысяч лет? Фиг его, сам по себе этот вопрос выходит за рамки науки, он сугубо философский. Нужно ли задаваться такими ненаучными вопросами? Наверное нужно и наверное это позволит улучшить качество самой науки, четко определить что такие-то вещи точно не познаваемы и не стоит даже пытаться развивать какие-то научные теории на эти темы. А может быть появится какая-нибудь наука о науке, в рамках которой будут искаться ответы на все эти вопросы. Хотя, блин, она уже есть, это философия науки ) Вся философия не нужна или философия науки пока сгодится? )

Короче, на мой взгляд, есть две крайности. 1) Наука не нужна, нужны только философы, пишущие пространные посты на хабре (к слову сам я не философ, у меня техническое образование) 2) Философия не нужна, нужна только наука. Я чё-то не готов принять одну из этих точек зрения, наверное истина где-то посередине.

Некомпетентные компетенции

Философия определяет мировоззрение людей. Например, вы задаёте вопрос "а что она может дать?" На курсе философии нам рассказывали, что такое утилитарное отношение к миру возникло относительно недавно, раньше или сейчас, но в других культурах, люди мыслят другими категориями. Польза от чего-либо не являются абсолютной ценностью, которая существовала и будет существовать везде и всегда. Ну, изучают люди философию, ну и пусть изучают, у меня нет ощущения, что они занимаются чем-то вредным или бесполезным. Я могу понять их.

Или ещё одна позиция "есть только наука, знания могут получаться исключительно эмпирически и никак иначе, а всё остальное - это лженаука, переливание из пустого в порожнее глупыми гуманитариями". А на курсе философии нам опять-таки рассказывали, что это всего лишь одно из течений философии - позитивизм. И есть огромное количество вопросов, которые в картину мира позитивистов не укладываются как бессмысленные. И в принципе, да, они вполне имели право утверждать, что например вопросы существования Бога, смысла жизни, первичности материи и сознания (живём ли мы в матрице) просто лишены смысла. Наш язык устроен так, что позволяет формулировать утверждения, которые нельзя ни подтвердить, ни опровергнуть. Позитивисты обнаружили это, хорошо изучили и описали, а потом Гёдель сформулировал теорему о неполноте. Или Бертран Рассел описал парадоксы теории множеств.

Т.е. нет такого, что философия закончилась в Древней Греции. Она оказывала огромное влияние вплоть до 20-го века на мировоззрение людей в целом и на науку в частности. Но почему-то вдруг в 2к22 философия устарела, и мы на столько преисполнились в своём научном познании мира, что с помощью науки можно найти ответы на все вопросы - у меня это не укладывается в голове.

Если коротко ответить на вопрос зачем нужна философия, то наверное чтобы выйти за рамки ограниченности своего мировоззрения. Не воспринимать разные вещи как абсолютную истину или как данность. Можно всю жизнь упарываться в зарабатывание денег, приобретение каких-то материальных благ, а потом осознать бессмысленность этого. Или жить в бочке, а потом осознать бессмысленность этого. А можно поизучать философию и не повторять ошибки людей живших тыщи лет назад, и упарываться во что-то другое.

Че-то коротко не получается ) Возможно философия нужна чтобы узнать что-то новое и интересное. Зачем, например, люди ходят в кино и смотрят какие-нибудь матрицы или читают Пелевина? Философы озадачивались всеми этими вопросами тыщи лет, думали о сложных и интересных вещах. И типа современные люди достигли такого уровня развития, что все эти философские размышления для них тривиальщина?

Лично мне были интересны разные вещи про связь мышления и языка (Витгенштейн, Фреге). В общем-то и в ИТ я занимаюсь разными моделями, формальными языками и т.п. Наверное мне что-то дало изучение философии.

Некомпетентные компетенции

Философия - одна из базовых дисциплин. Без неё не поступить в аспирантуру, не защитить диссертацию. А на западе PhD - это вообще доктор философии. Философия как бы мягко говоря не сопоставима с историей или географией :) Зачем она нужна? Ну, например, чтобы не застревать в позитивизме, который типа отрицает философию, но фактически является одним из её течений. Хотя с другой стороны, какое дело большинству людей до всяких позитивизмов, диссертаций и т.п. Да, и высшее образование фиг знает на сколько всем нужно.

Как бы вы реализовали форму аутентификации на сайте? Вопрос для собеседования на Junior/Middle/Senior?

Я бы ответил, что нужно взять готовое решение типа Keycloak, Ory, Avanpost, ... Но сначала посмотреть какая система уже используется у заказчика. Если никакая, то аналитик должен определить верхнеуровневые требования (например, нужна ли в принципе на этом конкретном сайте двухфакторная аутентификация), сделать обзор по существующим в мире системам идентификации и аутентификации пользователей, оценить их на соответствие требованиям, затем написать детальные постановки (например, с требованиями к правилам валидации вводимых данных). Затем можно начинать писать код. И конечно же после всего этого я был бы послан и с позором провалил собеседование, потому что от меня ожидали рассказ про необходимость хэширования паролей, и в итоге в опроснике было поставлено ноль галочек напротив правильных ответов.

8 правил, которые пригодятся при описании Git-коммитов

Рецензент читает это сообщение 5 секунд, а потом оно хранится в истории вечно. И например может использоваться как основа для листа изменений, в котором видимо всё таки должны описываться уже внесенные, а не планируемые изменения.

Причем для рецензента в принципе без разницы будет в сообщении "Добавить кнопку" или "Добавлена кнопка". Первый вариант обычно проще, потому что в такой форме описывается исходная задача и можно просто скопировать название задачи и не париться. Плюс в английском языке такие глаголы короче. Но в русском языке и с точки зрения последующего использования истории, на мой взгляд, второй вариант единственно возможный.

Все самые крутые решения в моей жизни — импульсивные. Как я стал senior-разработчиком в 17 лет

Да, тем более, тогда и не было никаких senior developer ) Если и были, то в параллельной реальности, и я о них не слышал. Весь этот хайп в ИТ, истории успеха, лычки и т.п. появились относительно недавно. Люди интересовались совершенно другими вещами, в ИТ точно шли не за деньгами и успехом.

Я думаю, что это неравенство работает и в обратную сторону:

senior developer != делать приложения

Для меня senior developer - это что-то про корпоративную или заказную разработку, про галеры. Скажем, Линус Торвальдс или Ричард Столлман - это синиор девелоперы? Возможно неудачные примеры, я не знаю деталей их биографии. Но я думаю, что есть разработчики, которые создают крутые приложения, но при этом корпоративная или заказная разработка им не интересна, прошла мимо них, или они ей занимались, но на вторых ролях, или их по этой шкале никогда не оценивали. А если бы оценили, то не факт, что взяли бы даже на роль джуна, по-моему такие примеры есть.

Ещё пара неравенств )

senior developer != senior developer

делать приложения != делать приложения

Все самые крутые решения в моей жизни — импульсивные. Как я стал senior-разработчиком в 17 лет

Возможно опыт провала проектов, чем больше тем лучше )

Я в 13-15 лет делал какие-то приложения из области кристаллографии. Пишешь любую формулу с двумя элементами типа NaCl, а тебе рисуется кристаллическая решетка и при этом красиво вращается в 3D - магия. UI был капец футуристичный, окошки и кнопки эффектно ездили по экрану. С клеточными автоматами игрался и т.п. Словом программировал для души. А сейчас люди сразу идут в кровавый энтерпрайз сеньорами рубить бабло. Жестокий мир ИТ...

А имеет ли Okta альтернативы?

Я плохо знаком с перечисленными системами. Но на сколько я понимаю, частая схема - это служба каталогов + Keycloak, Ory или Avanpost.

Как обнулить карму на Хабре

Есть такая идея, что нужно осуждать поступки людей, а не лично их. Не помню уже в каком паблике пацанских цитат, родительском чате или от какого психолога я это услышал. Когда ставят минус за комментарий, то это воспринимается как осуждение поступка, с этим многие люди могут смириться, понять и исправиться. А минус в карму воспринимается как личное осуждение самого человека. По-моему это достаточно деструктивно и в реальной жизни, и в инете, особенно если делается без какого-либо маломальского обоснования типа "я считаю лично тебя чмом, потому-то".

В чем смысл такой кармы - просто загадка. Это в чистом виде механизм анонимного и безнаказанного осуждения не каких-то конкретных проступков человека, а гнобление его лично.

Information

Rating
1,344-th
Registered
Activity