Долго выбирал между оптическим и нагрудным (жаба душила), в итоге взял Polar H7. Работаю с часами Polar A300. Что получилось в результате: https://youtu.be/nVfrZqShUEg
Первое правило — хренотень. Руководитель должен быть лидером, понимать устройство рынка, интересы бизнеса, потребности потребителей. Должен быть коммуникабельным, экстравертом, немного психологом, чтобы объединять вокруг себя умных людей и вести их в нужном направлении. Должен постоянно коммуницировать с «гуманитарными» сотрудниками (отделом продаж, отделом маркетинга и т.д.)
И вы хотите, чтоб он ещё и код писал? Да щас, блин.
Второе правило тоже хренотень. Даже лень объяснять почему.
Спрашивать алгоритмы на собеседовании — это такой способ самоидентификации в обществе, демонстрация принадлежности к социальной группе, как не показывать поворотники при перестроении — то есть, говорить «я п*дор». Просто на собеседовании неловко спросить кандидата, п*дор он или нет, вот они и маскируют вопрос под алгоритмы.
Вода, вода. Кругом — вода. Про самое главное не сказали не слова, поэтому, извините, скажу за вас. У разных операторов в разных городах (и даже областях) — разные частотные диапазоны, как это можно увидеть на картинке
Частота не зависит от «типа связи» (2G, 3G, 4G), а выдаётся надзорным органом для конкретной местности. Нормальная антенна ловит плюс-минус 100 от своей частоты, поэтому идея «универсальной антенны» под все — не более чем унылый маркетинговый трюк. Нужно в конкретной местности смотреть статистику, отдаваемую модемом, выяснять какой *конкретно здесь* используется BAND и какая частота, и подбирать антенну под неё.
Собственно главная беда реакта озвучена в самом начале: это не MVC, а только view-слой.
Поэтому, как только перед адептами реакта встаёт задача хоть немного манипулировать данными на фронтенде — они начинают ныть и плакать. Элементарные действия вроде сортировки или фильтрации коллекции по набору параметров превращаются в нелепый стыд и боль. Эй, парни! Разработка веб-приложений это на 99% работа с данными, и 1% с визуальным представлением, ау!
Но если мой сотрудник, в оплаченное мной рабочее время, занимается вложением себе в бошку каких-то знаний, эти знания должны быть экономически выгодны моему проекту в долгосрочной перспективе. Потому что иначе он работает мне в убыток, а себе в пользу.
Вся эта широко обсуждаемая байда о том, что программист должен всегда учиться, эгоцентрично ориентирована программистами на самих себя.
Программы пишутся не для того, чтобы они отрабатывали за сколько-то там миллисекунд или ради прочей ерунды. Программы пишутся для того, чтобы доходы от них были выше совокупных расходов. С этого надо начинать, а не с меряния пиписьками алгоритмами.
Дорогой автор! Любое новое знание, вкладываемое в голову, должно быть экономически оправдано. У вас в статье про это — ни слова.
Если среднестатический разработчик, работая в офисе 8 часов в день, внезапно вложит себе в бошку волшебное средство, которое ускорит его работу в два раза, это не значит что он будет зарабатывать в два раза больше денег. Это значит, что он будет пахать в два раза больше за то же время, потому что никто не оставит простаивающим дорогостоящий человекоресурс. Безусловно — круто для работодателя, но вот надо ли оно разработчику?
Я сам трепетно отношусь к алгоритмам и паттернам, продвигаемым IBM и Amazon. Я могу читать лекции о lock-free и темпоральных структурах данных и потоковых вычислениях. Но они не дают мне возможности пинком открывать дверь в отдел кадров любой конторы на рынке, и требовать тройное увеличение оклада. Потому что чем больше инструментов ты знаешь, тем меньше работодателей, где все эти инструменты востребованы одновременно.
В итоге специалист, отрастивший себе набор ускоспециализированных скиллов, оказывается тупо привязан к месту работы, потому что ну нет, блин, нет на рынке 100500 контор с необходимостью использовать красно-чёрные деревья или ручками писать сортировку пузырьком. Зато есть 100500 контор, готовых платить многозначную сумму в евро за общую адекватность, интуицию, широкий кругозор и способность делать поддерживаемый продукт на банальном пэхэпэ или руби.
Ну уволим мы всех, а работать-то кто остается? :) Сколько людей Вы лично наняли, за свою карьеру? Сколько команд построили с нуля?
Можно годами искать этих якобы «ответственных и понимающих», но факт в том что таких людей НЕТ. Или есть, но очень мало. Никто не сможет составить команду из 100% таких, тем более когда это надо сделать быстро в стартапе. Всегда найдутся либо добродушные косячники, либо клинические идиоты.
Поэтому нужно рассказывать сотрудникам, что такое хорошо и что такое плохо. Обучать их. Нужны грамотные, лаконичные инструкции, покрывающие как можно больше кейсов. Нужны инструменты, ведущие исполнителей по линиям бизнес-процессов (по «скриптам»), помогающие даже самому тупому и безответственному сотруднику правильно обслужить клиента даже в нестандартной ситуации.
уволенные сотрудники тендерного отдела всё возмущались — за что с нами так?!!! Мы же всё делали по инструкции…
А может, всё-таки накажем того идиота, кто эти инструкции писал? :)
Но нет, конечно проще всё свалить на безалаберность сотрудников, чем думать о бизнес-процессах.
Некогда ведь думать о бизнес-процессах, продавать надо. Стартап же.
Уходите от REST-а, вы его переросли. Переходите на AMQP (а именно RabbitMQ с роутингом). Это даст вам асинхронность и все преимущества event-based loose-coupling системы. В том числе такие приятные вещи, как параллелизация нагруженных узлов, кворумные воутеры, возможность рестарта любого сервиса без потерь, dry-run новых версий сервисов, debug «на ходу» и т.д.
А во вторых — очень любопытно, как вы решаете вопросы совместимости API при внесении breaking changes? Когда у вас десятки сервисов, предполагаю, вам нужно или передепловать всю кучу на новую версию API или поддерживать две версии одновременно. Как именно вы поступаете?
Я подразумеваю электрический плёночный тёплый пол — который рулонами раскатывается, как линолеум. И поверх него уже финишное покрытие — тот же ламинат, хотя бы. Да, дорого в установке — порядка 2000 рублей за квадратный метр только на сами материалы.
Он греет не постоянно, а включается релюшкой по датчику. Благодаря этому него расчётное потребление порядка 30 вт/м2, то есть для средней квартиры это сравнимо или даже меньше, чем затраты на освещение. Зато по нему безумно приятно ходить босыми ногами, и даже лежать на нём, как в турецкой бане. Боюсь, при обдуве сверху такого эффекта не будет — у них же первый этаж, под полом неотапливаемый подвал…
Судя по тому, что автор нас не комментирует, он на эту тему уже забил :)
Нет, это не лучший вариант.
Во-первых, канальный нагреватель — это чудовищные энергозатраты. Это же, по сути, фен — огромнейшая мощность в сравнении с небольшим полезным эффектом.
Во-вторых, у них на фотографиях разводка труб идёт по верху, а значит подаваемый тёплый воздух так и будет болтаться наверху, а внизу в районе ног будет вечный холод — причина простуд и эпидемий.
Более правильно было бы подавать внутрь холодный воздух, направляя потоки так чтобы они не целились людям за воротник, а подогревать помещение — электрическим (плёночным) тёплым полом.
И у вас в щитке я не заметил никаких УЗМ или аналогичных устройств, защищающих от перенапряжений в сети. Их нет или я протупил?
А, и ещё рулонные шторы надо в два слоя делать (два рулона, разматывающиеся параллельно). Первый слой — как у вас, лёгкая защита от солнца, а второй слой — blackout (так и называется у производителей) — толстый виниловый слой плёнки, полностью блокирующей солнечный свет. Полезно для использования видеопроектора, ну или в самый летний солнцепёк.
Говорю не голословно, потому что в своё время я подготовил офис для конторы UMI.CMS буквально from scratch — из заброшенного здания, без электричества, воды и отопления.
По моему опыту, приточка для средней квартиры делается своими руками в рамках бюджета 10-15 тысяч рублей. Большая часть ценника, который вам накрутили, это нафиг никому не нужная сборка комплектующих в единый корпус плюс собственно работа разгильдяев-монтажников.
Ваша вытяжка на «принципах естественных щелей» — это пережиток советской эпохи, когда в окнах были щели. Вам придётся открывать стеклопакеты зимой, чтобы она работала, и дуть холодом в сотрудников. А летом, по теплофизическим причинам, она работать не будет вообще.
Приточка — это настолько круто и правильно, что сейчас я сознательно избегаю работодателей, у которых её нет. Вам не нужна приточно-вытяжная установка, и тем более не нужна рекуперационная. Вам нужна простая приточка. Заложите себе её в бюджет на развитие, тем более что самая дорогая часть (дырки в несущей стене) и разводка труб под потолком у вас уже есть.
Ребят, вас десять лет назад заморозили в криогене, что-ли? Откуда водопад в разработке ПО в 2015-ом году? Так и напишите: мы делаем большие, неповоротливые продукты, с циклом развития в несколько лет, а потом их выкидываем и делаем заново, потому что таким способом нашим заказчикам более удобно пилить корпоративные бюджеты.
Претензиями обменялись, теперь можно говорить по делу :)
хочется услышать названия компаний, где финансовые операции делаются вне контекста транзакций
Я говорю не «где», а «если». Судя по всему, вы работаете в мире, где софт берётся от корпоративных производителей. Я работаю в мире, где софт пишется руками кого попало — кого удалось найти HR-службе. Огромное количество народу вообще не знает, что начисления и списания пишутся отдельными строчками в БД — эти люди просто инкрементируют или декрементируют значение в столбце balance в таблице users.
для мира реляционных БД с их старомодным ACID
ACID вам здесь не поможет, так как здесь он говорит лишь о том, что переход значения A в значение B в одной конкретной ячейке реляционной таблицы происходит «мгновенно» с точки зрения внешнего наблюдателя.
В то же время, рассмотрите пример: многие фреймворки для разработки сайтов предлагают следующий паттерн для денормализации: допустим, есть таблица users и таблица comments (со столбцом user_id в качестве указателя на автора комментария). И разработчику предлагается добавить в таблицу users столбец comments_count, значение в котором инкрементируется приложением (приложением! не триггером в БД!) сразу за фактом добавления каждого нового комментария. Пруфлинк, если что.
И вот вы сливаете дамп всех таблиц: слили comments, сливаете ещё 100500 таблиц по алфавиту, добрались до users. А у вас такие гиперактивные юзеры — они фигачат комменты по 1000 штук в секунду. И в конечном файле дампа, который вы попытаетесь восстановить после аварии, счётчики comments_count будут не соответствовать реальному количеству строк комментариев в сдампленной таблице comments. Всё — ваша целостность данных развалилась.
(конечно это решаемо тысячей разных путей, безусловно, но факт налицо)
Думаю, от таких хостеров надо бежать, а не рассуждать
Окей. Но покажите мне хоть одного хостера, предоставляющего услугу «виртуальный хостинг» (т.е. не виртуальный и не выделенный сервер), который бэкапит как-то иначе. Я за свою карьеру не встречал.
Где рассуждения о том, что нагруженная БД практически никогда длительно не находится в консистентном состоянии?
О том, что типичная услуга хостеров «бэкап путём снятия SQL-дампа» — это иллюзия, потому что на большом количестве таблиц пока идёт дамп первых таблиц — последние могут противоречиво обновиться?
О том, что момент бэкапа может попасть между финансовыми операциями (между тем как у юзера A списались деньги, а юзеру B — начислились), а разработчик приложения соответствующими инструментами (транзакциями) просто не владеет?
О том, что бывает шардинг и партиционирование на физически разных машинах, которые тоже нужно консистентно забэкапить?
Я считаю, что об этом было бы гораздо полезнее написать, чем о «следите за свободным местом на диске».
Передайте Матвиенко.
Долго выбирал между оптическим и нагрудным (жаба душила), в итоге взял Polar H7. Работаю с часами Polar A300. Что получилось в результате: https://youtu.be/nVfrZqShUEg
И вы хотите, чтоб он ещё и код писал? Да щас, блин.
Второе правило тоже хренотень. Даже лень объяснять почему.
Уфф, всю статью читал в напряжении, дойдете вы до шины данных с выбрасыванием эвентов, или нет. С этого надо было начинать :)
Респектище за статью и архитектуру, молодцы!
Письма, автореплаи, MS Outlook… В 2016-ом году?
Назовите компанию, в которой работаете, чтобы никто туда случайно не пошёл.
Частота не зависит от «типа связи» (2G, 3G, 4G), а выдаётся надзорным органом для конкретной местности. Нормальная антенна ловит плюс-минус 100 от своей частоты, поэтому идея «универсальной антенны» под все — не более чем унылый маркетинговый трюк. Нужно в конкретной местности смотреть статистику, отдаваемую модемом, выяснять какой *конкретно здесь* используется BAND и какая частота, и подбирать антенну под неё.
Поэтому, как только перед адептами реакта встаёт задача хоть немного манипулировать данными на фронтенде — они начинают ныть и плакать. Элементарные действия вроде сортировки или фильтрации коллекции по набору параметров превращаются в нелепый стыд и боль. Эй, парни! Разработка веб-приложений это на 99% работа с данными, и 1% с визуальным представлением, ау!
А так-то да, виртуальный дом, всё такое.
Но если мой сотрудник, в оплаченное мной рабочее время, занимается вложением себе в бошку каких-то знаний, эти знания должны быть экономически выгодны моему проекту в долгосрочной перспективе. Потому что иначе он работает мне в убыток, а себе в пользу.
Вся эта широко обсуждаемая байда о том, что программист должен всегда учиться, эгоцентрично ориентирована программистами на самих себя.
Программы пишутся не для того, чтобы они отрабатывали за сколько-то там миллисекунд или ради прочей ерунды. Программы пишутся для того, чтобы доходы от них были выше совокупных расходов. С этого надо начинать, а не с меряния
пиписькамиалгоритмами.Если среднестатический разработчик, работая в офисе 8 часов в день, внезапно вложит себе в бошку волшебное средство, которое ускорит его работу в два раза, это не значит что он будет зарабатывать в два раза больше денег. Это значит, что он будет пахать в два раза больше за то же время, потому что никто не оставит простаивающим дорогостоящий человекоресурс. Безусловно — круто для работодателя, но вот надо ли оно разработчику?
Я сам трепетно отношусь к алгоритмам и паттернам, продвигаемым IBM и Amazon. Я могу читать лекции о lock-free и темпоральных структурах данных и потоковых вычислениях. Но они не дают мне возможности пинком открывать дверь в отдел кадров любой конторы на рынке, и требовать тройное увеличение оклада. Потому что чем больше инструментов ты знаешь, тем меньше работодателей, где все эти инструменты востребованы одновременно.
В итоге специалист, отрастивший себе набор ускоспециализированных скиллов, оказывается тупо привязан к месту работы, потому что ну нет, блин, нет на рынке 100500 контор с необходимостью использовать красно-чёрные деревья или ручками писать сортировку пузырьком. Зато есть 100500 контор, готовых платить многозначную сумму в евро за общую адекватность, интуицию, широкий кругозор и способность делать поддерживаемый продукт на банальном пэхэпэ или руби.
Это рынок, чувак.
Можно годами искать этих якобы «ответственных и понимающих», но факт в том что таких людей НЕТ. Или есть, но очень мало. Никто не сможет составить команду из 100% таких, тем более когда это надо сделать быстро в стартапе. Всегда найдутся либо добродушные косячники, либо клинические идиоты.
Поэтому нужно рассказывать сотрудникам, что такое хорошо и что такое плохо. Обучать их. Нужны грамотные, лаконичные инструкции, покрывающие как можно больше кейсов. Нужны инструменты, ведущие исполнителей по линиям бизнес-процессов (по «скриптам»), помогающие даже самому тупому и безответственному сотруднику правильно обслужить клиента даже в нестандартной ситуации.
Но нет, конечно проще всё свалить на безалаберность сотрудников, чем думать о бизнес-процессах.
Некогда ведь думать о бизнес-процессах, продавать надо. Стартап же.
Уходите от REST-а, вы его переросли. Переходите на AMQP (а именно RabbitMQ с роутингом). Это даст вам асинхронность и все преимущества event-based loose-coupling системы. В том числе такие приятные вещи, как параллелизация нагруженных узлов, кворумные воутеры, возможность рестарта любого сервиса без потерь, dry-run новых версий сервисов, debug «на ходу» и т.д.
А во вторых — очень любопытно, как вы решаете вопросы совместимости API при внесении breaking changes? Когда у вас десятки сервисов, предполагаю, вам нужно или передепловать всю кучу на новую версию API или поддерживать две версии одновременно. Как именно вы поступаете?
Он греет не постоянно, а включается релюшкой по датчику. Благодаря этому него расчётное потребление порядка 30 вт/м2, то есть для средней квартиры это сравнимо или даже меньше, чем затраты на освещение. Зато по нему безумно приятно ходить босыми ногами, и даже лежать на нём, как в турецкой бане. Боюсь, при обдуве сверху такого эффекта не будет — у них же первый этаж, под полом неотапливаемый подвал…
Судя по тому, что автор нас не комментирует, он на эту тему уже забил :)
Во-первых, канальный нагреватель — это чудовищные энергозатраты. Это же, по сути, фен — огромнейшая мощность в сравнении с небольшим полезным эффектом.
Во-вторых, у них на фотографиях разводка труб идёт по верху, а значит подаваемый тёплый воздух так и будет болтаться наверху, а внизу в районе ног будет вечный холод — причина простуд и эпидемий.
Более правильно было бы подавать внутрь холодный воздух, направляя потоки так чтобы они не целились людям за воротник, а подогревать помещение — электрическим (плёночным) тёплым полом.
А, и ещё рулонные шторы надо в два слоя делать (два рулона, разматывающиеся параллельно). Первый слой — как у вас, лёгкая защита от солнца, а второй слой — blackout (так и называется у производителей) — толстый виниловый слой плёнки, полностью блокирующей солнечный свет. Полезно для использования видеопроектора, ну или в самый летний солнцепёк.
Говорю не голословно, потому что в своё время я подготовил офис для конторы UMI.CMS буквально from scratch — из заброшенного здания, без электричества, воды и отопления.
По моему опыту, приточка для средней квартиры делается своими руками в рамках бюджета 10-15 тысяч рублей. Большая часть ценника, который вам накрутили, это нафиг никому не нужная сборка комплектующих в единый корпус плюс собственно работа разгильдяев-монтажников.
Ваша вытяжка на «принципах естественных щелей» — это пережиток советской эпохи, когда в окнах были щели. Вам придётся открывать стеклопакеты зимой, чтобы она работала, и дуть холодом в сотрудников. А летом, по теплофизическим причинам, она работать не будет вообще.
Приточка — это настолько круто и правильно, что сейчас я сознательно избегаю работодателей, у которых её нет. Вам не нужна приточно-вытяжная установка, и тем более не нужна рекуперационная. Вам нужна простая приточка. Заложите себе её в бюджет на развитие, тем более что самая дорогая часть (дырки в несущей стене) и разводка труб под потолком у вас уже есть.
По крайней мере, будет честно.
Я говорю не «где», а «если». Судя по всему, вы работаете в мире, где софт берётся от корпоративных производителей. Я работаю в мире, где софт пишется руками кого попало — кого удалось найти HR-службе. Огромное количество народу вообще не знает, что начисления и списания пишутся отдельными строчками в БД — эти люди просто инкрементируют или декрементируют значение в столбце balance в таблице users.
ACID вам здесь не поможет, так как здесь он говорит лишь о том, что переход значения A в значение B в одной конкретной ячейке реляционной таблицы происходит «мгновенно» с точки зрения внешнего наблюдателя.
В то же время, рассмотрите пример: многие фреймворки для разработки сайтов предлагают следующий паттерн для денормализации: допустим, есть таблица users и таблица comments (со столбцом user_id в качестве указателя на автора комментария). И разработчику предлагается добавить в таблицу users столбец comments_count, значение в котором инкрементируется приложением (приложением! не триггером в БД!) сразу за фактом добавления каждого нового комментария. Пруфлинк, если что.
И вот вы сливаете дамп всех таблиц: слили comments, сливаете ещё 100500 таблиц по алфавиту, добрались до users. А у вас такие гиперактивные юзеры — они фигачат комменты по 1000 штук в секунду. И в конечном файле дампа, который вы попытаетесь восстановить после аварии, счётчики comments_count будут не соответствовать реальному количеству строк комментариев в сдампленной таблице comments. Всё — ваша целостность данных развалилась.
(конечно это решаемо тысячей разных путей, безусловно, но факт налицо)
Окей. Но покажите мне хоть одного хостера, предоставляющего услугу «виртуальный хостинг» (т.е. не виртуальный и не выделенный сервер), который бэкапит как-то иначе. Я за свою карьеру не встречал.
Что ещё обсудим? :) Any comments welcome!
Где рассуждения о том, что нагруженная БД практически никогда длительно не находится в консистентном состоянии?
О том, что типичная услуга хостеров «бэкап путём снятия SQL-дампа» — это иллюзия, потому что на большом количестве таблиц пока идёт дамп первых таблиц — последние могут противоречиво обновиться?
О том, что момент бэкапа может попасть между финансовыми операциями (между тем как у юзера A списались деньги, а юзеру B — начислились), а разработчик приложения соответствующими инструментами (транзакциями) просто не владеет?
О том, что бывает шардинг и партиционирование на физически разных машинах, которые тоже нужно консистентно забэкапить?
Я считаю, что об этом было бы гораздо полезнее написать, чем о «следите за свободным местом на диске».