Ура! Этот момент настал!

Первая книга о 3D печати и 3D принтерах на русском языке

Книга переведена и свёрстана! На это потребовался почти год, но уверяю, информация в книге более чем актуальная. Рекомендую книгу всем, кто хочет узнать больше о бюджетных 3D принтерах, хочет ближе с ними познакомиться.

Книга на данный момент является самым полным, актуальным, подробным и насыщенным источником знаний о бюджетных/персональных 3D принтерах и 3D печати. В книге рассказывается о предыстории 3D печати, о разновидностях принтеров (и преимуществах бюджетных перед промышленными), способах печати, программах 3D CAD моделирования (и преимуществах платных и бесплатных программ), даны основные определения по 3D печати, рассказывается о разнообразнейших методах применения персональных 3D принтеров, рассказывается о том как перерабатывая пластиковые отходы можно улучшить экологию и создать полезные вещи, о том как учить 3D печати детей. Осмелюсь сказать что представитель любой профессии с помощью этой книги поймёт и найдёт для себя преимущества 3D печати и почувствует весь тот потенциал, который она в себе содержит!

1. Это дешевле, чем приобрести уже собранный на месте
2. Это быстрее, чем ждать из Китая Anet A8 за 109$ (далее — обычный стиральный порошок3D-принтер)
3. Это более качественно (при некривых руках)

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

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

И только благодаря "Марсианскому правилу" итоговая сумма выросла всего на три вечнозеленых.
Но вопреки широко известному по фильму скотчу я использовал синюю (а как же без нее) изоленту и пластиковые стяжки.

В общем, если Вы только думаете собирать 3D-принтер — добро пожаловать под кат,
где будут мои соображения по поводу конструкции и сборки некоторых узлов.
Ибо подробных инструкций по сборке в интернете и так полно.

Классификация должностей в современных, особенно технологических компаниях сбивает с толку не только обилием сокращений и миксом терминов на двух языках, но и нюансами скрывающегося за ними содержания. Этому нигде не учат — понимание тонкостей, наполнения и специфики тех или иных должностей приходит с опытом и передаётся только с опытом. Со временем мы планируем систематизировать наши знания в этой области, но пока поговорим о насущном: в субботу в Москве состоится очередной Hiring Tournament. На турнир — точнее, сафари, — в котором сразу четыре софтверных компании DevFactory, Aurea, Ignite и Crossover вышли на охоту за головами редкого зверя Software Engineering Manager, пытаясь выманить его на годовой оклад в $100 000. Чем не повод поговорить о том, что это за создание и чем в корпоративных джунглях SEM отличается от должности-двойняшки — Team Lead.


Чем совершеннее в компании отлажены процессы — тем больше они напоминают конвейер вне зависимости от её профиля

Team Lead, особенно в небольших командах — это универсальный солдат, который и таски по команде раскидает, и сам за станок может встать, чтобы показать, как надо работать или закрыть собой дыру в ресурсах. В общем, тимлид он во всём тимлид — батя команды разработки.

Однако если в вашей компании имеются Software Engineering Manager, «семы» — то они тоже будут руководить командами разработчиков или инженеров, контролируя и обеспечивая работоспособность команды, и поддерживая рабочий контакт с «соседними» отделами разработки. Так в чём же разница с тимлидами? Мы попросили VP of Technical Product Management компании Aurea Software Максима Винникова помочь внести нам ясности в деталях.

Впервые о книге Фредерика Брукса я услышал лет десять назад, ещё учась в универе. Её настоятельно советовал почитать наш научный руководитель. Как часто бывает в таких случаях, когда кто-то вам советует что-то почитать, то вы вежливо говорите нечто вроде «да-да, в скором времени, непременно этим займусь», заносите очередной пункт в свой grow list (в лучшем случае) и благополучно об этом забываете.



Через пару лет я вернулся к этой книге и наконец с ней ознакомился. К тому моменту у меня уже было несколько лет работы в IT-индустрии. И когда я начал читать, то удивился, насколько книга, написанная в 1975, да ещё и в сфере разработки ПО, по-прежнему актуальна!

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

Всем привет! В нашем совместном с МФТИ учебном проекте Технотрек есть семестровый курс по Product Management. Меня зовут Станислав, и я ведущий преподаватель этого курса, а также менеджер продукта в проекте DonationAlerts. Готовясь к курсу, я собрал внушительный список полезных материалов. Сделал для вас из этого списка подборку книг и блогов, которые будут полезны менеджерам продуктов или проектов.

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

Все мы прекрасно знаем о том, как разрабатывается ПО. Подумали 10 минут и сразу пошли кодить. Цикл создания программного обеспечения состоит из многих ключевых моментов. Это такие моменты как планирование, создания архитектуры, создание SRS, создание дизайна и тд и тп.

Введение

Недавно ко мне обратились, чтобы я посоветовал стандарты для написания технического задания (ТЗ) на разработку автоматизированных систем (АС) и программного обеспечения (ПО). Вот думаю, сейчас зайду в Яндекс, найду подходящую статейку и отправлю её. Но не тут-то было! Одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашел. Придется сделать такую статейку самому…

И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):

• ГОСТ 34
• ГОСТ 19
• IEEE STD 830-1998
• ISO/IEC/ IEEE 29148-2011
• RUP
• SWEBOK, BABOK и пр.

25 апреля в рамках «Дня тренинга МГУ 2020» Алексей Каптерев выступил с докладом про критическое мышление. Представляем вам расшифровку лекции.

Введение

Меня зовут Алексей, я тренер по презентациям. Мое знакомство с темой критического мышления началось с презентации. Я даже помню с какой конкретно презентации, человек по имени Эми Кадди на конференции TED. Эта презентация бешено популярная, несколько месяцев назад там было 48 млн. просмотров, это вторая по популярности презентация на этом сайте, должно быть, это неплохая презентация.

^{Длинный материал. Время чтения – около 40 минут.}



Доктор Ричард Хэмминг, профессор морской школы Монтерея в штате Калифорния и отставной учёный Bell Labs, прочёл 7 марта 1986 года очень интересную и стимулирующую лекцию «Вы и ваши исследования» переполненной аудитории примерно из 200 сотрудников и гостей Bellcore на семинаре в серии коллоквиумов в Bell Communications Research. Эта лекция описывает наблюдения Хэмминга в части вопроса «Почему так мало учёных делают значительный вклад в науку и так многие оказываются в долгосрочной перспективе забыты?». В течение своей более чем сорокалетней карьеры, тридцать лет которой прошли в Bell Laboratories, он сделал ряд прямых наблюдений, задавал учёным очень острые вопросы о том, что, как, откуда, почему они делали и что они делали, изучал жизни великих учёных и великие достижения, и вёл интроспекцию и изучал теории креативности. Эта лекция о том, что он узнал о свойствах отдельных учёных, их способностях, чертах, привычках работы, мироощущении и философии.

Концепт изготовления подарка от гика.



Сокро грядёт Новый Год, день святого Велентина, восьмое марта. Да много чего ещё грядёт, и вот хочется подготовить сани летом, телегу зимой, в общем основательно подготовиться к сиим праздничным событиям и порадовать нашу вторую половину чем-то необычным. На мой взгляд, самый бесценный подарок — это подарок, который сделан своими руками. Отсюда и будем плясать.

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

Когда я сижу, у меня болит спина.

Это происходит уже последние 10 лет. И неважно, где я нахожусь – на работе, в ресторане, даже дома на диване. Моя поясница кричит: «Прекрати сидеть!»

Чтобы уменьшить боли в спине, на работу я купила себе коленный стул. Потом стол для работы стоя. Потом вернулась к обычному стулу, потому что мне стало больно стоять.

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

Эти средства немного помогли – сначала. Но боль так и не ушла. Поэтому несколько лет назад я решила принять это как должное: сидячее положение причиняет мне боль, и так будет всегда.

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

Источник

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

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

Анализируя свой опыт по построению диаграмм и систематизируя удачные находки и ошибки пользователей, я выработал набор принципов, которые позволяют строить хорошие диаграммы.

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

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

В основе любого графического представления данных лежит его композиция — соотношение и взаимное расположение частей данного представления. Удачное композиционное решение может сделать диаграмму проще для понимания, обогатить её дополнительным смыслом и повысить её привлекательность. К сожалению, чтобы отыскать такую композицию, нужно обладать композиционным чутьём и опытом, однако, если следовать определённым правилам, можно получить вполне сносный результат, даже будучи новичком. Сначала рассмотрим технический подход к поиску композиционного решения.

Несмотря на то, что Altium Designer поставляется с огромными библиотеками компонентов по-прежнему остается необходимость создания в нем своих схемных компонентов. Особенно это актуально для крупных микросхем с большим количеством выводов и атрибутов выводов. Это могут быть FPGA, микроконтроллеры, процессоры, чипы памяти и т.д. Здесь я представлю свою технологию генерации схемных компонентов экстрагируя информацию из PDF файлов.

Важнейшим вопросом в разработке радиоэлектронных устройств всегда является вопрос «сколько это будет стоить?» Причем точный ответ желательно знать еще до того, как вы втянулись в дебри разработки и вложились в нее временем и средствами. Чаще всего разработчики сосредотачивают внимание на себестоимости комплектующих.

На самом деле, расчет себестоимости по списку деталей — это неприятный и рутинный процесс, связанный с долгими поисками по on-line каталогам, обзвоном дистрибуторов, перепиской и ожиданием ответов и проч. и проч. Но хуже даже не это, а то, что это итерационный процесс. Увидев вдруг, что себестоимость оказалась выше допустимой, разработчик начинает искать другие варианты схемотехники и другие комплектующие. И снова поиски…. А рутина — это враг разработчика. Чтобы ее избежать, многие жертвуют оптимальностью. Но, к счастью, эту проблему можно облегчить.