Внешний вид шикарен, после уже приевшегося Bootstrap, даже несмотря на приевшийся flat стиль. Но авторы сильно прокосячили прямо на главной странице, сравнивая свою «семантическую» сетку, с «несемантической» сеткой нового TB.
У нового TB сетка — mobile first, отсюда и различного рода col-lg-4, так как у колонки может быть одновременно несколько разных классов, от разных сеток, для разных размеров страницы. И при таком раскладе, красивые лаконичные классы Semantic UI абсолютно бесполезны, и при попытке работать в таком ключе будет больше путаницы.
Можно присоединиться к Google+ сообществу, и не только знать о предстоящих мероприятиях, но также принимать участие во всякого рода обсуждениях и hangout'ах — plus.google.com/communities/117927540789820622012, которые надо сказать происходят с завидной частотой.
А во сколько вы оцените ущерб от более низкой квалификации, проблем из-за неправильной эксплуатации интернет-проектов? Сколько времени вам понадобится, чтобы приобрести тот же опыт, который вам дадут на курсе?
Типичное русское мышление — лучше дешево сейчас, чем в десятки раз дороже в перспективе.
Как вариант, но ИМХО, не так показательно. Нужно что-то более контрастное. А так, привычный PHP (с ошибками дизайна, но мы о них прекрасно знаем, и многие к этому привыкли), и C# — отличный язык (если не считать, что многим он не подходит из-за ориентированности на проприетарную платформу).
Простите, но это очередной пост, где смешались и кони, и люди.
1) Тестирование — это тестирование корректности работы программы, а не проверка, что везде передаются значения определенного типа. Сколько раз уже обсуждали — один черт, опять в кучу.
2) Очередное непонимание типизации. Проблемы не в статическая/динамическая, а в строгая/слабая.
Почему, в каждом каноническом примере про типизацию присутствует Haskell (где программы — это архитектура типов больше, чем алгоритмов), и канонический пример динамического языка (со строгой типизацией, кстати) — Python. А почему никто не делал сравнения С++ (с его выкрутасами над шаблонами) и Erlang (язык-то динамически типизированный, но при этом есть анализ кода и типов). Хватит избитых примеров, и хватит непонятных сравнений.
Интересно, а насколько популярно мнение о том, что взаимосвязи между постами вовсе и нет?
Я могу все понять, но наряду с любой из теорий, имеет шанс быть и теория о том, что сообщество реддита охвачена идеей фикс о том, что это какие-то взаимосвязанные послания, тогда как автор просто стебется над этим самым сообществом.
У меня напрашивается. Я вообще впервые слышу про Siesta, и вообще про платный (!) фреймворк тестирования на JS. В связи с чем вопрос. Почему именно он, и почему не использовать Jasmine или Mocha, которые уже имеют кучу готовых инструментов для прогона их как в браузере, так и на фантоме, да еще и кучу интеграций с различными веб-фреймворками.
В результате, меня волнует секрет успеха этого фреймворка, если для того, чтобы запускать тесты на фантоме в платной версии надо плясать с бубном.
Bootstrap на less потому что им уже сползать поздно, и он умеет на клиенте компилироваться. Но LESS действительно теряет позиции, и не только за счет SASS, но например еще за счет rework или stylus.
Звучит безумно, но многое понятно из того, что боты — это команда рубистов, а значит это:
— разработка через тестирование;
— применение различных ООП практик;
— выразительный и компактный синтаксис;
— DSL.
Учитывая эти вещи — 5 строк на метод не такое безумство как кажется. Вот к примеру, методика TDD. Вы пишете сначала тест. Чтобы его написать, вы должны подумать, что будет делать к примеру метод. Пока вы будете думать, вы оцените его потенциальную сложность, и уже на этом этапе попробуете его упростить так, чтобы его можно было очень просто протестировать.
То есть, сами применяемые методологии подталкивают к таким ограничениям.
Code review — это отдельно взятая ситуация. Но не всегда она имеет место быть. Как и наличие адекватного review'ра. Review'ер может быть адекватным, но иметь какой-то уровень доверия к тому или иному разработчику, чтобы проверять документацию. Ну в общем, допущений в реальной жизни слишком много, ИМХО.
Ну я к тому, что «наболевшее» можно обсудить в сообществе, и узнать, кто к каким практикам пришел. Можно конечно и на хабре, но когда есть тематическое сообщество — почему нет? (=
У нового TB сетка — mobile first, отсюда и различного рода col-lg-4, так как у колонки может быть одновременно несколько разных классов, от разных сеток, для разных размеров страницы. И при таком раскладе, красивые лаконичные классы Semantic UI абсолютно бесполезны, и при попытке работать в таком ключе будет больше путаницы.
Типичное русское мышление — лучше дешево сейчас, чем в десятки раз дороже в перспективе.
1) Тестирование — это тестирование корректности работы программы, а не проверка, что везде передаются значения определенного типа. Сколько раз уже обсуждали — один черт, опять в кучу.
2) Очередное непонимание типизации. Проблемы не в статическая/динамическая, а в строгая/слабая.
Почему, в каждом каноническом примере про типизацию присутствует Haskell (где программы — это архитектура типов больше, чем алгоритмов), и канонический пример динамического языка (со строгой типизацией, кстати) — Python. А почему никто не делал сравнения С++ (с его выкрутасами над шаблонами) и Erlang (язык-то динамически типизированный, но при этом есть анализ кода и типов). Хватит избитых примеров, и хватит непонятных сравнений.
Я могу все понять, но наряду с любой из теорий, имеет шанс быть и теория о том, что сообщество реддита охвачена идеей фикс о том, что это какие-то взаимосвязанные послания, тогда как автор просто стебется над этим самым сообществом.
В результате, меня волнует секрет успеха этого фреймворка, если для того, чтобы запускать тесты на фантоме в платной версии надо плясать с бубном.
— разработка через тестирование;
— применение различных ООП практик;
— выразительный и компактный синтаксис;
— DSL.
Учитывая эти вещи — 5 строк на метод не такое безумство как кажется. Вот к примеру, методика TDD. Вы пишете сначала тест. Чтобы его написать, вы должны подумать, что будет делать к примеру метод. Пока вы будете думать, вы оцените его потенциальную сложность, и уже на этом этапе попробуете его упростить так, чтобы его можно было очень просто протестировать.
То есть, сами применяемые методологии подталкивают к таким ограничениям.