• Одиннадцать ошибок управления проектами на примере трансатлантического яхтенного перехода
    +1
    По личному опыту складывается ровно такое же ощущение:
    Проектный менеджмент — это очевидные, общие и довольно прописные истины.
    Проблема в том, что для каждого практического кейса — фраз, описывающих решение оной — несколько десятков. Рабочих из них около десятка, уместных 1-2. Поэтому хорошие статьи по проектному менеджменту очень часто смотрятся как исповедь капитана очевидность. Тем не менее таковыми не являются.
    Воспринимайте статью как очевидное перечисление очевидных областей с тем чтобы вы проделали неочевидное для своего проекта — и прошлись по этим областям чтобы понять — закрыты ли они у вас осознанно или «сложились исторически и не очень выгодно».
  • Кровь, пот и слезы дизайнера
    0
    А вы думаете, каждый человек должен стремиться к выдающемуся успеху? Или достаточно просто умения обеспечить достойную жизнь?
  • Квест от ЕРАМ: пять задач с собеседований по .NET
    +6
    Сложность алгоритма — функция от объема входных данных (и еще некоторых параметров)
    Сложность функции — эммм…?

    Скорее задача должна звучать как — расположите данные функции по эммм… ну я даже не знаю, по скорости роста на больших N…

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

    Итого — подойдет чтобы отсеять слабых джуниоров и найти джуниоров посерьезнее. Для практикующих программистов, увы, не репрезентативно.
  • Из разработчиков — в Solution Architects: история одной трансформации
    +2
    Совершенно не претендую на то, чтобы быть опытным enterprise архитектором, но, быть может дело в том, что Ваш вопрос не совсем простой? (Например, потому, что он у вас возник).

    Вообще, про ваш вопрос хотелось бы узнать больше контекста — потому что пока чувствуется некоторый месс — микросервисы, воркфлоу,… В каком вы технологическом стеке вообще? Какова текущая архитектура системы?

    Для вопроса в вакууме кажется — что ваш юзер-сервис уже немножко перерос один сервис и требует быть разделенным на сервис, предоставляющий наружу атомарные операции с пользователями (создать/изменить/etc...) — другой сервис отвечает за создание воркфлоу для пользователя, третий — хранит логику достаточную для принятия решения о том для каких изменений запускать воркфлоу, а для каких жить напрямую. — он и выставляется наружу.

    «Нормальный архитектор со стажем решал эту проблему уже много раз» — Неа. Не решал ее нормальный архитектор. Другие задачи решал, а конкретно эту задачу не решал абстрактный нормальный архитектор. Ну вот не свезло ему.

    P.S. Понимаю Вашу проблему в целом — отсутствие внешнего комьюнити. Хотя бы просто потому что архитектурные вопросы требуют серьезного погружения в тему каждый раз, когда возникают — а это — лень, да и времени жалко. Но тут как и везде — не хватает комьюнити — создай его :-)
  • Тёмный путь
    +7
    Такое ощущение, что человек написавший это, при всем уважении, не совсем понимает что такое Optional type.
    Это не про NPE, а про, черт возьми, настоящую строгую типизированность. Когда сущность какого-то типа обозначает именно сущность этого типа, а не «Стринг — это, конечно, Стринг, но иногда еще и null».

    Я не знаю кейса, когда из-за этого не хватило какой-то гибкости языка.

    P.S.
    А теперь вопрос. Кто должен разруливать все эти риски? Язык? Или это работа программиста?


    Работа программиста — фичи деливерить, а не выдавать код нравящийся кому бы то ни было. Если какая-то функциональность позволяет деливерить фичи быстрее с более высоким уровнем качества, не повышая при этом существенно порог входа в технологию (возможно при этом мешая нескольким фрикам делать какую-то жесть) — эта функциональность хорошая.
  • Когда вредно тестировать ваши компоненты
    +3
    Дело в том, что сам компонент написан плохо. Код для фильтрации нельзя использовать повторно. Если нам понадобится фильтрация в другом компоненте, то при таком подходе придется писать и тестировать все заново.Нарушен принцип единственности ответственности.

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


    1. Если нам понадобится применять ровно эту фильтрацию в другом месте… А если не понадобится?

    2. Если мы протестировали код для фильтрации в другом месте — по-хорошему, при тестировании компонента мы должны протестировать, что он вызывает именно эту функцию фильтрации, а не какую-то другую. Так как это внутренняя и неявная зависимость модуля, фактически, для формальной чистоты — мы должны прогнать тесты, которые покроют эту зависимость.
  • Каково оно учить JavaScript в 2016
    0
    Некоторые вещи концептуальны) Это как доказательство в математике :-D — его полезность измеряется не объемом, а тем, насколько полезные результаты дает применение результата и насколько долго не могли получить это доказательство. Redux — это концептуальная штука, как раз. Фреймворк, навязывающий некоторые стиль написания кода. Я не буду сейчас утверждать, что это ограничение спасет вас от всех проблем — но, anyway — не стоит недооценивать его значимость)
  • Un-FuckUp-able Development Protocol (UDP)
    +1
    Вообще, есть в этом прекрасном рассуждении тонкий флёр исключительности, заключающийся в том, что постулируется, что работа программиста по дефолту сложнее работы по выстраиванию коммуникаций или качественному менеджменту.
    Команда с Джун-менеджером и Сеньор-программистом навоюет ненамного больше, чем команда с Сеньор-менеджером и Джун-программистом.

    Поэтому конечно джуны и мидлы справятся с этой необязательной и несложной задачей, а по-настоящему сложные задачу останутся разработчикам… Для сложных проектов умение держать в голове достаточный контекст проекта для формулирования требований и общения с компетентными(подчеркну это слово — потому что да, такие бывают далеко не в каждом проекте) представителями заказчика — требует не меньший уровень сеньорити, чем собственно написание кода.
  • Как подобрать ITшника в России: миф №2, №3
    +11
    Маркетинговый стартап размышляет (ну, если можно это так назвать) о промышленной разработке программных продуктов?
    Erlang и SmallTalk в одном предложении тоже доставляют. Мне кажется, не хватает Assembler, Fortran и Brainfuck
    Не очень понятно, что за мифы? В какой они среде гуляют? Я вот, например, об этих распространенных мифах даже не слышал.
    Ну и да — 3 абзаца на две статьи — это за гранью.

    В общем блин. Жаль, что
    -мегамозг закрылся
    -в карму можно ставить только один минус
  • Swift 3.0, много шума, а что на деле?
    +1
    О, вот прям с утра от знакомых еще один прилетел:

    http://openradar.appspot.com/radar?id=4971716266688512
  • Swift 3.0, много шума, а что на деле?
    +2
    https://bugs.swift.org/browse/SR-1502 вот, например. Страшный.
  • Swift 3.0, много шума, а что на деле?
    +5
    ввиде багов с ооочень долгим компиляцией массива

    Это далеко не самый страшный баг свифта) но вернуться на обж-си я уже не могу, глаза вытекают…
  • Конкурс на лучшую публикацию про разработку, дизайн или тестирование мобильного приложения
    +6
    Аргументированная критика? Ну… Это хорошая тема — когда за 600 долларов вложений вы планируете найти 3 клиентов — уже взрослых продуктов. Я полагал это стоит дороже)
  • Введение в RxJava: Создание последовательности
    0
    тестируется как и любой другой хороший фреймворк.

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

    Благодарю за беседу)
  • Введение в RxJava: Создание последовательности
    0
    Большой профит RX — он очень хорошо тестируется. Соответственно если при разработке приложения высокие требования к качеству — я буду смотреть в сторону RX.

    Засчет биндинга — он очень хорошо покрывает задачи где данные собираются больше чем с одного источника (неважно — разные эндпоинты API, системные ресурсы, БДшечка) и претерпевают какие-то преобразования попути. То есть очень похоже на развитие идей LINQ.

    Минус — Быстродействие — соответственно — если у меня много разных маленьких элементиков и требования к 60fps — выберу что-то более простое и прямое

    RX очень требователен к уровню команды — соответственно с разномастной командой я бы в RX не ввязывался — его невозможно отлаживать — только тестировать.

    То есть если я буду писать быстрый прототипчик чего-нибудь или игру, или буду работать в команде возможностей которой я не знаю — я, вероятно, выберу не RX
    Если я буду писать алгоритмически сложную задачу требовательную к ресурсам и нуждающуюся в магии — я выберу не RX
    Иначе — RX
  • Введение в RxJava: Создание последовательности
    0
    … а выше вы же писали, что чтобы реактивщина была семантически точной, ее нужно правильно готовить, что не очень просто.

    Могу раскрыть мысль — выработка хорошего подхода при работе с реактивным кодом требует существенных затрат в начале. И Вообще имеет высокий порог входа. Однако после преодоления этого порога оказалось, что в итоговом коде нет проблем, которые возникали при аспектном подходе (хотя я не исключаю, что просто неправильно его готовил)

    На мой взгляд эти два подхода просто решают различные задачи, хотя оба лежат в области стиля организации кода и борьбы с проблемами асинхронности, как вы упомянули
  • Введение в RxJava: Создание последовательности
    0
    Хорошо. Странно говорить «Лучше всех» в IT — где каждое решение — компромисс))
    Разные классы сущностей. Потоки RX — не про потоки и асинхронность — а про контракт монадного биндинга в первую очередь — то есть про декларативное описание последовательности действий.
    Акторы больше похожи на аспектный подход.
    Их странно сравнивать) Но если очень хочется — то по моему опыту. аспекты гораздо гибче и дают больший эффект при меньших вложениях сил — однако больше тяготеют к потере контроля над качеством кодовой базы.
  • Введение в RxJava: Создание последовательности
    0
    Так может быть, если есть более простые способы достигнуть семантической точности (я сейчас не буду обсуждать семантическую точность полученной реактивщины, ее надо почитать для этого на конкретных примерах), не надо усложнять?

    Да — вы правы — тут уже надо брать куски кода и разговаривать по ним. С чем сравниваю? Ну, скажем, со «средним по больнице» iOS репозиториям на гитхабе, с кодом в статьях и так далее, да я полагаю — что реактивный подход действительно хорошо справляется с задачей честного описания стейта сущности (включая транзитный) даже на уровне сигнатур.
  • Введение в RxJava: Создание последовательности
    0
    А вы уверены, что речь идет о «против сиюминутной выгоды», а не «против семантической точности», скажем?

    Ну вообще практика показывает — что правильно приготовленная реактивщина очень и очень семантически точна, но вопрос очень уместный — потому что правильно ее приготовить не очень просто. Насчет избыточности? Возникало такое ощущение, да, но в итоге пришел к тому, что это приемлемая цена за тестируемый код, с гарантированно меньшим количеством сайд-эффектов и высоким уровнем инкапсуляции

    К сожалению, презентация заточена под устный доклад — поэтому возможно чего-то будет не хватать — но с удовольствием объясню все недостающее при желании узнать. Ссылко
  • Введение в RxJava: Создание последовательности
    +1
    С точки зрения молотка все — гвозди. И да, так можно жить, но это не всегда удобно.

    разумеется RX не панацея — но цель автора статья, да и моя — показать, что это достаточно взрослая парадигма для того, чтобы занимать ключевую позицию в реальных задачах.
  • Введение в RxJava: Создание последовательности
    +1
    А надо ли вызывать этот флоу, или он на самом деле актуален только для первого логина, а релогин — это совсем другое?

    Нет, не надо — это разные задачи. Которые можно описать единообразно.

    С точки зрения молотка все — гвозди. И да, так можно жить, но это не всегда удобно.

    И это правда. И тут имеет место tradeoff — консистентность против сиюминутной выгоды. На текущем проекте на данный момент первое выигрывает — но у меня нет оснований говорить что так будет всегда

    Хм, можете показать пример чистого Rx, описывающий «последовательность» из стартового коммента — мне интересно, насколько это будет читабельно.

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

    я легко и бегло это читаю, потому что я привык

    Вот завтра как раз на докладе и узнаю :-) Простой ли это код, или просто привычный)
  • Введение в RxJava: Создание последовательности
    0
    Ну вот здесь на самом деле вопрос — что такое одиночная операция.

    Кнопка, скажем — не одиночная операция — а сигнал нажатий на нее
    Логин — не одиночная операция — любой запрос тебе может вернуть 403, и ты зарелогинишься, вызвав при этом какой-то навешенный на это флоу.
    И так далее.

    Вообще с точки зрения реактивщины — почти все — стримы, сиречь множественные операции — а что одиночные — в общем-то и не стоит отдельного эффорта.

    Пы-сы. Да, если ваш язык поддерживает async workflows… Ну мой язык, скажем, не поддерживает) и опять же с точки зрения реактивного программировния и прочих биндингов — все эти асинки-авэйты лишь частный случай преобразований control/data flow — и этим прекрасны.

    Вообще из всех моих личных комплейнтов к реактивщине — она всегда читабельна. Но иногда несет избыточный бойлер с потерей производительности.
  • Введение в RxJava: Создание последовательности
    +1
    Да в общем-то низачем. RX он даже не про асинхронность, а про chaining — это способ консистентно и декларативно описать разнородную последовательность операций. Когда у тебя поток шлет лишь один value — это превращается в обычную future.
    Иметь консистентный способ проводить преобразования этих самых фьюч и не заботиться о том, моментальная эта операция или растянутая во времени, синхронная или асинхронная.

    Концепция биндинга экономит много времени на кофе и комментарии на хабре :-)

    А достигнуть сходного качества организации кода можно и без RX.
    В чем плюс RX в этом смысле — что когда появятся более настоящие RX задачи — они в строятся в остальной код таким образом, что никто этого и не заметит
  • Переход на ReactiveCocoa v.4
    0
    чем больше используешь РАК, тем больше приходишь к тому, что его не просто сложно — а нельзя дебажить, отлаживать и т.п. и приходится продумывать другие паттерны повышения качества приложения. Например РАК — ооочень легко тестировать
  • Математика на пальцах: методы наименьших квадратов
    0
    просто читайте соответствующие материалы, там все написано) http://mathworld.wolfram.com/Cosine.html
  • Математика на пальцах: методы наименьших квадратов
    +1
    Тогда вам, вероятно, следует ознакомиться еще лишний раз с тем, что такое косинус.
    Есть наивное определение cos — отношения катета к гипотенузе, по сути функция (R+, R+) -> R[-1, 1] (из двух положительных действительных чисел в действительное на отрезке [-1, 1])
    Оперировать двумя числами неудобно — поэтому (R+, R+) была заменена на R — угол. итого мы имеем функцию
    cos® -> R[-1, 1]
    Но ведь согласитесь, где вы видели прямоугольный треугольник с одним из углов равным -1345 градусам? Уже в этот момент мы отошли от наивного определения.

    После того, как в математике появились комплексные числа — все стандартные функции были расширены на комплексную плоскость. В том числе и тригонометрические — и оказалось, что cos© уже не попадает в R[-1, 1] и может принимать сколь угодно большие значения — в том числе и -2.
  • Математика на пальцах: методы наименьших квадратов
    0
    Эммм… Дело в том, что под cos^(-1) тут следует понимать не 1/cos, а arccos, тогда не встает ли все на места?)
  • Опыт лекций по введению в шаблоны проектирования
    +4
    И вроде бы Success, но… фраза «А если завтра сменится поставщик БД»? Так почему бы завтра и не решить этот вопрос?
    Гораздо неудобнее будет, если он никогда не сменится, а время потрачено.
  • Опыт лекций по введению в шаблоны проектирования
    +2
    Нарушаем. этот класс «Считает И делегирует» а не только считает и только делегирует. На мой взгляд, корректно этот вопрос решает FRP — добавить третий метод в интерфейс класса — который будет возвращать стрим простых чисел — на который на другом уровне мы можем уже навесить печать — ибо разные задачи.
    А необходимость передавать управления внутри шага алгоритма вызвана лишь наложенными самостоятельно (не необходимыми) ограничениями о том, что мы должны вернуть массив И напечатать.
  • Опыт лекций по введению в шаблоны проектирования
    +4
    Зависимость PrimeNumberCalculator от Console кажется притянутой за уши. При решении реальных задач — это прямое нарушение SRP
  • Зимняя стажировка для разработчиков в Redmadrobot
    0
    Учитывая то, что мне пока ни разу не довелось натыкаться на не то что одинаковые интерпретации MVVM в разных проектах, но даже и MVC — то вполне могут оказаться полезными знаниями (ну или на самом деле очередной интепретацией MVVM :-) ) )
  • Swift! Protocol Oriented
    0
    В obj-c не сделаешь миксинов, как вы и описали — протоколов не привязанных к типу.

    Зачем они могут быть нужны?
    Самый явный пример — уточнение дженериков.
    Если не вдаваться в библиотеки (мы, например, очень любим писать расширения к generic сущности SignalProducer из ReactiveCocoa) — то в коде встречались расширения на Optional на конкретные типы.
    Пример — единообразный анврап Optional объекта (замена конструкции value = optional ?? fallbackValue на какую-то единообразную optional.unwrap, которая предпочтительнее, чем unwrap(optional)). Для того чтобы его написать — нужно уметь строить fallbackValue — что можно сделать только для какого-то набора типов.
  • Как иногда плохой код и антипаттерн решают
    +2
    Для этого неплохо подходит реактивщина и DI — в одном месте создается сервис, который содержит в себе ваши часто изменяющиеся данные — а дальше во все заинтересованные части приложения рассовываются стримы — иными словами неизменяемые «обсерверы», которые сработают в момент, когда эти данные обновились — и — отдельно — в заинтересованные сущности, которые могут менять эти данные — инжектятся «синки» — иными словами лямбды, в которые можно засунуть новое значение.

    Таким образом у нас нет способа получить значение этих данных, кроме как среагировав на него и нет способа изменить его, кроме как через этот синк.

    Хранить же эти данные можно и так как описали вы. Важно — как вы предоставляете доступ к этим данным.
  • Как иногда плохой код и антипаттерн решают
    +3
    Важно, что в синглтоне — потому что синглтон — это shared state протянутый через все приложение.
    Если ты изменил этот стейт — то не факт что все потребители этого синглтона ожидают это изменение и правильно на него среагируют. И проверить, что ты ничего не сломал можно только либо «регрессионным тестированием» мануальных QA, либо верой, что «я же четкий, я ж не сломал»

    В этом и фундаментальное отличие синглтона от несинглтона — область видимости обычного объекта позволяет локализовать потенциальные места для возникновения ошибки, а синглтона — нет.
  • Как иногда плохой код и антипаттерн решают
    0
    Чтоб вам этот синглтон и классы его использующие покрыть регрессионными тестами, чтобы оценили, почему плохо.

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

    То есть код для фриланса, с которым, конечно, можно мириться, но гордиться и защищать — не стоит)
  • Objective-C что такое на самом деле метод и self? + runtime
    0
    Там не особо интересно и ничего особо нового, хотя есть ряд восхитительных грабель, когда пытаешься подменить имплементацию метода на блок.
  • Swift 2 в быту. Еще один парсер JSON
    +1
    Не думаю, что прямо таки общие корни — большинство новейших языков неслабо между собой похожи. Скорее они пытаются решить одни и те же наболевшие вопросы.
    P.S. я тоже жду, что (когда) откроют исходники — так как мне видится неплохое будущее у этого языка — и я бы хотел, чтобы он развивался шире
  • Как web-студии из Зеленограда запустить многомиллионный start-up и не помереть
    0
    И все это мы упёрто делаем по 10–14 часов в сутки и почти без выходных.

    А все «ядро компании» в заметной доле? Или кто-то таки за зарплату работает по столько времени с гордостью?
  • Пишем реализацию Observer-а над KVO на objective-c
    0
    Вот, вы приводите как раз превосходные примеры атомарных моделей. В которых нам интересно изменение всего состояния авторизации, либо же сети, а не одного из 5 полей, что значительно упрощает работу по организации подписки — как через Notification Center, так и через KVO или же множественное делегирование, реализованное, как-нибудь иначе.

    У меня вызывает вопросы как раз необходимость дробления модели до ее полей.
  • Пишем реализацию Observer-а над KVO на objective-c
    +1
    Вообще, стоит архитектурно очень качественно подумать — а правильно ли организованы потоки данных в приложении, если есть изменяемая модель с несколькими слушателями. Необходимость такого — это, скорее, исключение, чем правило.

    Могу порекомендовать подробно поизучать ReactiveCocoa и прочие порты Rx — оно, конечно, оверкилл с точки зрения производительности — но при осознанном использовнии невероятно упрощает поддержку кода бизнес-слоя.