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


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

Проблема

Во многих местах существует разрыв между обучением компьютерной науке и потребностями индустрии. Взгляните на следующую ситуацию:
Знаменитый профессор компьютерной науки (с гордостью): «Мы не учим программированию; мы обучаем компьютерной науке.»
Производственный менеджер: «Они не способны программировать.»

Во многом они оба правы, и не только на поверхностном уровне. Задача научного сообщества состоит не в том, чтобы обучать посредственных программистов, а индустрия не требует только «всесторонне развитых, высокообразованных мыслителей» и «учёных».

Другой профессор компьютерной науки: «Я не написал ни одной строчки кода.»

Здравствуй, хабра-человек.
Как известно, Microsoft очень хорошо потрудилась над своим последним детищем по имени Windows 7 и внесла много различных нововведений, об одном из которых я и хочу рассказать. Особенно актуально, я думаю, это будет для владельцев ноутбуков и нетбуков, но и пользователи настольных систем так же могут получить профит.
Как известно, самое большое новшество в «семерке» (после GUI) — это переработанная подсистема ACPI. Тут и нормальная поддержка многоядерных систем, и управление питанием устройств, мониторинга аппаратных средств, да и много чего еще, но одна очень интересная возможность остается за кадром — речь идет об энергопотреблении и управлении ядрами многоядерных/многопроцессорных систем.

Понадобилось мне недавно сделать казалось бы простейшую вещь, а именно с помощью некоторой формы на сайте отправить письмо с вложением. И сделать это надо на сайте, построенном на Друпале… Как оказалось, этот пост очень правильный — действительно нужные рецепты не найдешь даже погуглив. В рунете вообще плохо с информацией, на диком западе получше, однако по теме ничего путного найти не удалось, кроме одного способа, который требует установки двух довольно навороченных модулей — ну это просто, по-моему, ни в какие ворота… Как и в случае с джумлой, пришлось копать сорсы различных модулей, api.drupal.org ну и, разумеется, додумывать. Результаты размышлений предлагаю Вашему вниманию. На примере простейшего модуля я покажу один из способов отправки сообщения с вложением по e-mail.

Продолжаем тему LaTeX + диплом.

Понадобилось мне написать диплом. Времени в обрез, требования жесткие. Материал есть, текст почти готов, надо оформлять. Сел, подумал, и решил, что ручной версткой уж точно заниматься не хочется. Из опыта участия во всевозможных олимпиадах вспомнилось, что лучше час потерять, но сделать решение, которое потом пройдет тесты, чем сразу сделать что-то и потому судорожно переделывать. Плюс к тому хотелось таки заняться плотным изучением Latex и компании.

Побудила писать этот код меня только одна вещь — тупые FTP некоторых хостеров.
Нет, файлы заливаются с максимальной скоростью, но вот между окончанием загрузки одного файла и началом загрузки следующего проходит секунд 30.
Так как я сейчас страдаю хренью верстаю и ставлю джомлы в ударных количествах, загрузка 5000+ файлов приводит к зачитыванию хабры и гуглридера до дыр, что однако тоже вредно для здоровья.
С целью исправить сиё досадное упущение и пишется небольшой наколеночный скриптик.

В гости на хабраинтервью к нам идёт Сергей Белоусов, один из самых успешных IT-предпринимателей России, чья биография с точки зрения количества созданных компаний, как он сам признаётся, скорее не является примером для подражания — слишком много было этих бизнесов.

Этот 38-летний бизнесмен после окончания физтеха стал соучредителем десятка компаний, в том числе Solomon Software, ASP Linux, Acronis, Infra Telesystems и SWsoft. Последняя в январе 2008 года была переименована в Parallels. Именно на ней Сергей концентрирует сейчас все свои силы, являясь генеральным директором.

Parallels создана российскими инженерами-программистами в Сингапуре в 1999 году (Белоусов имеет сингапурское гражданство). Штат компании около 700 человек. Штаб-квартира находится в Швейцарии. Разработка и вся техподдержка — в Москве и Новосибирске.

В последние годы Сергей Белоусов дал много интервью, в том числе на Хабре, Эхе и в Радио-Т), так что сложно найти вопросы, на которые он ещё не отвечал. Под хабракатом — некоторые цитаты из его прошлых интервью.

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

На время тестирования сайт расположен по адресу rospil.info
Ресурс с трудом работает под натиском хабраэффекта.

Cайт работает в режиме тестирования, возможны любые изменения. Основная версия будет доступна по адресу rospil.net

Ресурс посвящен борьбе с коррумпированными чиновниками, которые используют систему государственных закупок для личного обогащения. Заявляется цель — сбор информации о воровстве, а так же конкретная работа по каждому конкурсу с привлечением экспертов. Вместе спокойно и последовательно добъемся устранения нарушений по одному конкурсу и привлечения к ответственности жуликов, вместо сотни бессмысленных показных скандалов в духе «все плохо и все своровали».

Прочитав «Веб-сокеты временно отменяются», не смог удержаться и решил ответить.

На мысль написать эту статью меня натолкнул вот этот топик. В нём завязался интересный разговор по теме найма IT специалистов и админов в частности. В этом топике я изложу свою идею о том, как стоит проводить собеседование с потенциальным сотрудником. Много размышлений, много воды, субъективность всего текста, многое прямо противоречит мнению многих рекрутеров о том, «как все же выбрать правильного админа».

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

Топик, на мой взгляд, стоит считать актуальным если вы нанимаете кого-либо из следующего персонала: helpdesk, эникейщика, офисного системного администратора (не корпоративного гуру), техсаппорт (не блондинку для первой линии) на хостинг или провайдеру, сервисного инженера, системного администратора технической поддержки (в хороших компаниях есть и такое, не удивляйтесь), приходящего системного администратора. Всех их в рамках статьи объединяет одно — их работа связана в первую очередь с решением проблем-вопросов, поступающих от пользователей (почему — ответ в статье). Всех их я объединю словом Админ, чтобы не выводить много знаков.

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

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

Ладно. Введение это очень весело, но вы его все равно не читаете, так что кому интересно — добро пожаловать под кат!

Всем привет, и ещё раз всех с прошедшими праздниками. Трудовые будни набирают обороты и вместе с ними растёт информационный голод мучающий нас. Мир разработки переднего конца не дремлет и готовит нам много сюрпризов в наступившем году, и уж поверьте мне, скучно не будет ни кому. Одна из новых особенностей которые нам готовят разработчики браузеров совместно с группами разработчиков пишущих спецификации — JavaScript Promises(далее в переводе — Обещания, прошу сильно не бить) — полюбившийся многим шаблон написания асинхронного кода обзаводится нативной поддержкой. Что же такое обещания и с чем их едят можно прочесть в нижеследующем переводе(слегка вольном) замечательной статьи Джейка Арчибальда.

Признак того, что объект не должен быть классом — если в нём всего 2 метода, и один из них — инициализация, __init__. Каждый раз видя это, подумайте: «наверное, мне нужна просто одна функция».

Каждый раз когда из написанного класса вы создаёте всего один экземпляр, используете только раз и тут же выбрасываете, следует думать: «ой, надо бы это отрефакторить! Можно сделать проще, намного проще!»

Перевод доклада Джэка Дидриха, одного из ключевых разработчиков языка Питон. Доклад прозвучал 9 марта 2012 на конференции PyCon US.

В свое время, так как я много времени проводил в командировках, мной была приобретена замечательная игрушка — usb модем Huawei e1550. Но времена лихой молодости прошли, и необходимость в использовании данного девайса по прямому назначению отпала. Так он и пылился у меня на полке в течении нескольких лет. И пылился бы и дальше, но возникла задача сделать систему оповещения. Тут я и вспомнил про модем. Рассмотрев поставленную задачу — был вынужден отказаться от SMS оповещения в пользу голосового дозвона по причине невозможности получить уведомление о прочтении SMS. Решения на базе Asterisk показались мне несколько громоздкими, и почитав доку по модему я решил написать звонилку самостоятельно.

Причина публикации.

Несмотря на обилие статей по работе с USSD и SMS запросами, я не нашел ни одной реализации голосовых вызовов на скриптовых языках (таких как Perl, PHP, Node.js). Надеюсь данная статья будет для Вас хорошим подспорьем.

От переводчика: предлагаю вашему вниманию вольный перевод статьи из блога Code Climate под названием 7 Patterns to Refactor Fat ActiveRecord Models.
Code Climate — мощное средство анализа качества кода и безопасности Ruby on Rails — приложений.

Введение

Когда разработчики начинают использовать Code Climate для улучшения качества их Rails-кода, им приходится избегать «распухания» кода их моделей, так как модели с большим количеством кода создают проблемы при сопровождении больших приложений. Инкапсуляция логики предметной области в моделях лучше, чем помещение этой логики в контроллеры, однако такие модели обычно нарушают Принцип единственной обязанности (Single Responsibility Principle). К примеру, если поместить в класс User все что относится к пользователю — это далеко не единственная обязанность.

Что за Rack?

По словам Christian Neukirchen — автора гема rack — он создан для обеспечения минимального API для подключения веб-серверов, поддерживающих Ruby (WEBrick, Mongrel и т.д.) и ruby веб-фреймворками (Rails, Sinatra и др.).

Такие фреймворки, как например Sinatra, построены над Rack или у них есть rack-интерфейс, позволяющий серверам веб-приложений подключаться к ним.

Цель rack проста — он позволяет с легкостью обрабатывать HTTP-запросы.

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

Проблемы git-flow

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

Однако и у git-flow есть проблемы. Я не раз слыхал мнения людей, выражавших неприязнь к тому, что ветви фич отходят от develop вместо master, или к манере обращения с хотфиксами, но эти проблемы сравнительно невелики.

Для меня одной из более крупных проблем git-flow стала его сложность — бóльшая, чем на самом деле требуется большинству разработчиков и рабочих групп. Его сложность ужé привела к появлению скрипта-помощника для поддержания рабочего процесса. Само по себе это круто, но проблема в том, что помощник работает не из GUI Git, а из командной строки, и получается, что те самые люди, которым необходимо действительно хорошо выучить сложный рабочий процесс, потому что им вручную придётся пройти все шаги его — для этих-то людей система и недостаточно удобна для того, чтобы использовать её из командной строки. Вот что становится крупною проблемою.

Все эти проблемы можно без труда преодолеть, следуя гораздо более простому рабочему процессу. Мы не пользуемся git-flow в Гитхабе. Наш рабочий процесс основан (и всегда был основан) на более простом подходе к Git.

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

Рабочий процесс Гитхаба

Наверняка многие из хабралюдей уже видели модель «Самого бесполезного устройства». Кто не помнит, это замечательное устройство выглядит вот так:


Обычно такие занимательные вещи хочется попробовать сделать самому…

Слишком часто стала мелькать в западных блогах и твиттере аббревиатура “DCI”. Меня удивил тот факт, что на хабре по данной тематике почти нету информации, лишь в Ruby NoName Podcast S04E09 упоминалось об этом. Любопытство взяло вверх, и я решил узнать об этом загадочном слове побольше. В процессе поиска я наткнулся на хорошую статью, написанную на английском моим земляком, Виктором Савкиным. Данная статья без обильной теории, на практических примерах показывает, что из себя представляет DCI. Далее повествование будет идти от лица Виктора.

Память наше всё!

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

Здравствуйте, уважаемые хабрачитатели. В этой статье я хотел бы поделиться знаниями об одном небольшом и простом, но полезном шаблоне, про который обычно не пишут в книжках (возможно, потому, что он является частным случаем шаблона «Команда»). Это шаблон «Правила» (Rules Pattern). Вероятно, для многих он будет очень знакомым, но кому-то будет интересно с ним познакомиться.