Pull to refresh
52
0
Алексей Золотых @zolotyh

Team Lead

Send message

Это мало о чем говорит без пояснений.

Было бы здорово, если бы вы написали чуть подробнее о самом фреймворке. Сейчас непонятно, чем он отличается от уже существующих.

Мнение Кента Бека (автор методологии) насчет стратегии написания авто тестов https://stackoverflow.com/questions/153234/how-deep-are-your-unit-tests/153565#153565.

В соседнем комментарии упомянули JQuery. Он сейчас является страшнейшим легаси. Вот у меня к вам вопрос: он был хорошим? Решал ли он задачи? Кажется что просто пришло его время. А JQuery, кто бы что не говорил, прекрасен. Точно также и с Dart. Думаю что основная проблема в том, что AngularDart все.

Я думаю что чтобы сказать точно нужно очень большую работу провести. Когда я там работал пару лет назад, мне казалось что от Dart больше пользы.

Wrike выпустил много успешных фич на Dart. Успех ведь не в том, чтобы остаться со стеком навсегда. Не задумывался почему деньги позволяли?

Для начала просто думать над происходящем в этом ключе. Дальше смотреть по ситуации. Стратегически нужно отвязать человека от его идеи. То есть показать, что от того, что идея хорошая или плохая человек не становится лучше или хуже. Может перекликается с «Пожертвовать сливой, чтобы спасти персик». Например уступить в части конфликта, но зато не отступить в принципиальном. Последний тезис конечно субъективен. У вас все может быть сложнее

Вы молодец! Спасибо вам за защиту Хабра от смуты, теперь я спокоен

Да не переживайте вы так за меня. У меня все хорошо. А за Хазанова спасибо! Очень его люблю
… ни «импликация», ни «булева алгебра» — тут ровным счётом непричём

Похоже вы начинаете понимать…
Кажется, что вы больше сосредоточены на форме (Если A, то B). Но форма сокращенная. Полная форма выглядит так: если не доказано обратное, то я буду считать, что человек умный. Я выбрал это сокращение по аналогии с презумпцией ума. Ее полная форма выглядит аналогично. Обратите внимание, что в этом случае пример с тортом становится менее абсурдным.

Иногда может потребоваться вернуть пустую строку. Как тогда отличать этот случай от случая, когда что-то идёт не так? И ещё один вопрос: что делать с другими, более развесистыми типами и более сложными случаями? Длинна строки обычно считается по месту, IMHO метод ей не нужен.

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

Но когда я что-то заливал в репозиторий, никто не мог понять, «что там еще за сложные типы». Я объяснял на дейли снова и снова, но натыкался на полный игнор. Энтузиазм и вера в правоту настолько придавали сил, что был почти уверен — скоро результат переломит недопонимание. Наконец в репо заглянул лид, и увидев там только типы, посчитал, что я нихера не делаю

Хрен знает, чем он слушал на дейли.


Выглядит не сильно убедительно. То есть я сказал, и дальше ваша проблема, что вы меня не слушаете и что вы поняли. Может быть нужно в этот момент оставновиться, согласовать действия с лидом? Я сильно сомневаюсь, что цель лида помешать расти прекрасным и универсальным инструменам любой ценой и душить мотивацию сотрудников на корню.
При этом вопросы и к лиду тоже есть, почему он не был в курсе процесса по задаче? Почему он не знал, что в рамках задачи нужно сделать и почему сейчас что-то другое делается?
Я конечно не знаю как это у вас, но обычно со стороны лида это выглядит так:
1. Согласовали кусок работы, выбили время
2. Декомпозировали задачу, разбили на куски
3. Разраб берет первый кусок задачи, начинает делать. Находит новую идею:
  «делать сильную систему типов» Начинает делать ее.
4. Сроки по куску провалены. Разраб говорит, что возникли проблемы, он их решил и следующая часть будет готова в срок. На самом деле дальше пилит идею. И вовсе не уверен в сроках, возможно даже о них не думает.
5. Результат: ничего не сделано или сделано не то, о чем договаривались или сделано больше чем то, о чем договариваись
6. Тимлид думает, что его обманули, разработчик, что его идею недооценили.
Софт скил для менеджера заключался в том, чтобы устранить проблему и договориться после фейла первой части, если задача декомпозирована (Если не декомпозирована, то это тоже проблема). Софт скил разраба здесь в том, чтобы постараться понятно объяснить для чего он делает и почему и если с ним сразу не согласились, то не делать этого, пока все не согласятся.
Полезность решения выношу за скобки. Тяжело решить насколько решение уместно без мнения второй стороны. 
Смущает формулировка:
Мне поручили разработку внутренней платформенной тулзы — библиотеки для выражения программных сущностей в виде объектно-ориентированных моделей и для однообразной работы с API сервисов
.
Насколько вы уверены, что с той и другой стороны правильно понимали задачу? Насколько это начинание изначально было поддеражно всей командой?
Вот вам пример. Цикл for одно время работал быстрее, чем вызов того же forEach из массива. Думаю что и сейчас ничего не поменялось, но всякое бывает. Если следовать вашей логике, то программист который впринципе использовал тогда forEach был неквалифицирован. Я не про области а про преджевременную оптимизацию
Меня пугает суждение о неквалифицированности.
Я не к словам придираюсь, я просто утверждаю что использование или неиспользование кода, который ведет к оптимизации на основе мономорфизма ничего не говорит о квлификации программиста от слова «совсем». А вы говоите, что это очевидно. Не очевидно.
Это явно говорит о неквалифицированном программисте, который плохо знает javascript


Вот здесь поподробнее
Язык должен помогать писать производительный код, что typescript безусловно и делает. Или пытается. Доказать или опровергнуть данное мнение очень трудоемко. Да и не нужно. Сильно сомневаюсь, что кто-то из-за производительности серьезно рассматривает typescript. Его сила явно в другом.
Писать все время быстрый код, как вы предлагаете программистам – это тоже плохо. Получится что-то нечитаемое и неподдерживаемое. По-моему правильно сначала писать что-то читаемое и поддерживаемое, а потом уже искать места где можно оптимизировать. Получается, что программисты пишут код в одном стиле, а бенчмарки пишутся в другом. Тоже вполне себе проблема.
Про мир в целом согласен. Один electron чего стоит. Но это не значит, что людей не беспокоит эта проблема. Так что все по классике. Чем больше беспокоимся, тем медленней работает.

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Works in
Date of birth
Registered
Activity