User
Многие слышали о великом и ужасном быстром преобразовании Фурье (БПФ / FFT — fast fourier transform) — но как его можно применять для решения практических задач за исключением JPEG/MPEG сжатия и разложения звука по частотам (эквалайзеры и проч.) — зачастую остается неясным вопросом.
Язык — лишь малая часть того, что вам нужно знать. Может быть около 5%, а то и меньше.
Софт постоянно усложняется. Стабильность и простота расширения приложения напрямую зависят от качества кода.
К сожалению, почти каждый разработчик, и я в том числе, в своей работе сталкивается с кодом плохого качества. И это — болото. У такого кода есть токсичные признаки:
Всем знакомы высказывания «я не понимаю, как работает этот код», «бредовый код», «этот код сложно изменить» и другие.
Однажды мой коллега уволился, потому что пытался справиться с REST API на Ruby, который было трудно поддерживать. Он получил этот проект от предыдущей команды разработчиков.
Исправление текущих ошибок создавало новые, добавление новых функций рождало новую серию ошибок, и так далее (хрупкий код). Клиент не хотел перестраивать приложение, делать ему удобную структуру, и разработчик принял правильное решение — уволиться.
Такие ситуации случаются часто, и это печально. Но что делать?
Определение Докера в Википедии звучит так:
программное обеспечение для автоматизации развёртывания и управления приложениями в среде виртуализации на уровне операционной системы; позволяет «упаковать» приложение со всем его окружением и зависимостями в контейнер, а также предоставляет среду по управлению контейнерами.
Ого! Как много информации.
11010000 10010100 11010001 10000000 11010001 10000011 11010000 10110111 11010001 10001100 11010001 10001111 00101100 00100000 11010001 10000001 00100000 11010000 10110100 11010000 10111101 11010000 10110101 11010000 10111100 00100000 11010000 10111111 11010001 10000000 11010000 10111110 11010000 10110011 11010001 10000000 11010000 10110000 11010000 10111100 11010000 10111100 11010000 10111000 11010001 10000001 11010001 10000010 11010000 10110000 00100001 00100000 00111010 00101001!
В мире JavaScript очень легко набрать свой стек технологий, используя набор небольших пакетов, каждый из которых решают свою конкретную проблему. И это хорошо, c одной стороны, а с другой стороны, у вас особо нет выбора — фреймворки которые выполняют широкий спектр задач в JavaScript не популярны.
В этом цикле статей я хочу поделиться своим практическим опытом построения JS стека.
Привет, Хабр!
Последние несколько месяцев мы в Хекслете работали над новыми курсами и обновлениями платформы. Сейчас на сайте доступно четыре "профессии", так мы называем последовательные программы обучения по разным направлениям, от новичка до джуниора. Одна из профессий окончена, а в остальных продолжают выходить новые курсы. Сегодня хочу рассказать про самое важное для нас сегодня направление — JavaScript, в частности профессию "Фронтэнд JS-программист".
Мы пошли не стандартным путем "hello world, сделаем форму, добавим анимацию, изучим ООП", а взяли за основу подход к изучению программирования в целом, а не конкретно языка JavaScript. Язык же используется как инструмент решения задач и применения изученных концепций и идей. При это мы изучаем свежий стандарт ES6 и с самого начала знакомим учащихся с правильным окружениям и техниками: модули, пакетный менеджер, отладка, модульное тестирование.
Вот как выглядит программа обучения:
