Введение в проблему

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

Недавно в RSS пришла статья, которую хотел оформить переводом — So you just deleted your production database — what now?. Однако комментарии к статье, да и последний абзац заставили задуматься — а на сколько просто восстановить удаленную базу данных.
И дабы не плодить непроверенной информации — перевод перевоплотился в исследование метода восстановления информации из случайно удаленной базы MySQL.

Привет, Хабражитель!

Многие люди мечтают научиться писать программы, игры, но не получается по многим причинам. Я, изначально, не хотел ничего писать потому что не было интересной платформы, и я был еще слишком маленьким. Потом все изменилось. Наступила новая эра в телефонной индустрии – появился iPhone. Я сразу, как о нем услышал, загорелся желанием его приобрести. Платформа сразу понравилась, кнопок и стилуса нет – самое то для игр.
Программы я начал писать в ноябре 2009, если их можно назвать программами :). Многие спрашивают как я учился – на видео-уроках с YouTube, а как еще? Читать непонятные уроки по iPhone SDK? В тот момент я загорелся идеей учить таких же как я – начал записывать видео на YouTube новым для меня темам.
Если интересно: http://bit.ly/pdyoutube. Потом все пошло и поехало, сам стал лучше программировать и запоминалось все намного лучше. Не буду писать очень длинное вступление – перейдем к самому интересному.

Всегда хотел делать игры, но на пустом Xcode не очень удобно и понятно. Стал выбирать платформу (фреймворк) для разработки игр под iPhone, iPad. Мой выбор остановился на Cocos2D. Многие спросят почему – он очень простой в использовании, очень! Он еще и бесплатный и часто обновляемый!

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

Сдача результатов работы является одним из самых драматических этапов проекта. Человеко-месяцы, потраченные на разработку, отладку, тестирование и внедрение вашего решения, не должны быть потрачены зря. Если сдача работ поручена вам, то ваша роль в команде весьма значительна, а доверие руководства велико, даже если начальники вам этого никогда не говорили. Облажаться на сдаче работ иногда означает конец вашей блистательной карьеры. Так что лучше этого не делать.

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

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

В комментариях к моей предыдущей статье amarao задал мне очень хороший вопрос. Он спрашивал, как именно, пользуясь какими правилами, мы ищем уязвимости в программном обеспечении. Приведу часть этого вопроса:

По каким алгоритмам, по каким правилам? Или это всё на наитии «а я знаю что такое mim!»? В этом случае метод не описывает ровным случаем ничего где-то — подумал, где-то нет.

Этим вопросом amarao, вольно или невольно, привлекает внимание к проблеме объективности при оценке уязвимости программного обеспечения, насколько эта оценка зависит, или не зависит, от эксперта, ее проводящего. Вопрос является очень важным, и поэтому часто возникает как у специалистов по безопасности, так и у наших клиентов.
Действительно, если мы не имеем возможности объективно оценить безопасность предлагаемых нам продуктов, то как мы можем выбрать из них один, наилучшим образом удовлетворяющий нашим потребностям? Все производители, естественно, будут клясться, что именно их продукт — самый безопасный из когда-либо созданных. Более того, каждый из них, возможно, будет в это верить, причем, верить с полным на то основанием.
Кажется, что оценка программного обеспечения независимыми компаниями — например, сертификация — может решить эту проблему. Но если не существует объективного средства анализа, то, как мы можем проверить качество самой оценки? Ведь оценка программного продукта в этом случае — сама по себе продукт, услуга.
Несмотря на то, что эти вопросы обсуждаются достаточно часто, я не видел однозначного ответа на них. Но за время моей работы в этой области у меня сложились определенные представления о возможностях современных методик.
В этой статье я хочу проиллюстрировать следующую свою мысль: сегодня не существует алгоритма поиска уязвимостей, который бы гарантировал объективную оценку безопасности. Поэтому доверие к продукту может основываться только на репутации экспертов, проводивших его оценку, и на опыте его эксплуатации (по сути, на репутации взломщиков, которые пытались преодолеть защиту).

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

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

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

Итак, займемся классификацией троллей и их приемов. Сегодня — формальный троллинг. В другой раз троллинг очный.

Начало и оглавление см. в первой части.

А что можно было бы ожидать на следующий год после IPO?

Через год после (описанного в предыдущей главе) удачного IPO (хоть и прошедшего со слабеньким P/E равным 12.5) пять акций Пети стоят 2500 долларов, а пропорциональная его доле часть прибыли составляет 950 долларов. Настало время готовить годовой отчёт…

В текущем проекте возникла необходимость выполнить последовательную серию ajax запросов и, по завершении — что-то сделать со всеми их результатами.
Довольно типовая задача, паттерн ее решения обычно называют waterfall (водопад). Реализации этого паттерна есть для node.js, хотя некоторые работают и в браузере — async.
Но включать целый модуль ради одного метода не хотелось. Copy/paste тоже не стал делать, но по соображениям скорее эстетическим. В async в метод передается функция обратного вызова, у нас же везде используется jQuery.Deferred. Разницы, конечно, никакой, но «ломать» стиль проекта мое «чувство прекрасного» мне не позволило :)
В результате написал небольшую утилитку по аналогии с jQuery.when

У самого ubuntu нету, поэтому попросили разместить. Думаю статья окажется полезной.

Еще в прошлом году на Хабре вышла статья о «релаксирующем» текстовом редакторе Ommwriter. Специфическая визуальная оболочка не могла не привлечь графоманов, нуждающихся в полном погружении в процесс написания текста. К сожалению, на момент выхода статьи хабраюзера langolf (а, впрочем, и до сих пор) не вышло ни одной версии для Linux.

Однако, это не означает, что аналогов Ommwriter не существует. Я был порядочно удивлен, случайно узнав о существовании многих программ, подходящих для такого рода графоманства. Поэтому мною был подготовлен небольшой обзор «focus on writing» текстовых редакторов для Linux.

Предыдущая часть: habrahabr.ru/post/119407

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

Карьера сисадмина

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

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

Как только у вас появилось свободное время — вы снова стоите на концептуальном перепутье. Вы можете просто продолжать работать администратором, и делать это долгое время. У вас будет копиться опыт, ваше резюме будет становиться всё менее и менее крикливым, а ожидаемая сумма будет постепенно расти, у вас появится сколько-то настоящих success story… Так может продолжаться неограниченно долго. Более того, про эту стадию сисадминства чуть ли не легенды складывают «я всё настроил и могу заниматься чем хочу», «чем больше админ работает, тем хуже он», «хороший админ должен бездельничать, пока сервера работают» и т.д.

Но что дальше? А дальше изменения могут быть только с вашей стороны. Вы можете либо продолжать стихийное развите «под потребности работодателя», либо начать выстраивать собственную специализацию. При этом «развитие под потребности работодателя» у вас будет идти спорадически, т.к. бизнесу в моменты затишья ничего не нужно нового от ИТ, нужно, чтобы оно продолжало работать. Для настоящего развития нужно смотреть глубже, и свободное время тратить не на исполнение обязанностей офисного планктона, а на обучение (если вы думали, что пройдя путь от аникея до «крутого админа» мучения с книжками/мануалами закончатся — не мечтайте).

Потребности бизнеса

Кстати, о потребностях бизнеса (поскольку деньги платит именно он, то именно он и определяет ситуацию на рынке труда)

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

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

В этой части статьи я напишу о вертикальном маргине. О горизонтальном поговорим в следующей части.

Начало и оглавление см. в первой части.

Неужели те деньги, что владельцы (фирмы, выпускающей акции) получают единоразово, окупают очевидную потерю части денег из-за передачи акций (а следовательно — и части владения компаний, а следовательно — и части прибыли) в чужие руки?

При оценке рынком стоимости акций прибыль — только один из учитываемых пунктов. Рынок может переоценить какую-то компанию или даже целую отрасль, если посчитает, что у неё очень хорошие перспективы.

Приветствую, хаброжители.

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

Microsoft наконец-то огласила результаты конкурса HTML5 приложений dev:unplugged с задержкой на 2 с половиной недели от первоначальных сроков. А ведь я чуть ли не каждый час обновлял браузер начиная с 23-его мая в надежде узнать результаты =) но статья не об этом…

Наш проект браузерной стратегии The Fate of Nation получил место среди «Honorable Mentions». Топовых победителей можно посмотреть на сайте конкурса.

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

Добрый день. Один из самых частых вопросов про LibCanvas сейчас — «С чего начать?». Согласен, порог вхождения в эту библиотеку чуть выше, чем в более простые canvas-библиотеки, потому в этом топике я раскрою основы LibCanvas — базовые понятия и принципы, отрисовка примитивных фигур, события мыши, клавиатуры, анимация, расширенный контекст, поведения. Постараюсь описать всё это с множеством примеров и максимально доступным языком.

Надеюсь, статья даст ответы на вопросы: Что такое LibCanvas? Зачем он нужен и какие его преимущества? С чего начать?

В этой статье будет только теория, а как применить эти знания на практике раскрыто в следующей статье

Начало и оглавление см. в первой части.

А что вообще такое — «биржа»?

Представьте себе магазин, в котором продаётся картошка.

Одним из незамеченных героев вселенной HTML5 является XMLHttpRequest 2. Строго говоря XHR2 не является частью HTML5 и не является самостоятельным объектом. XHR2 это тот же XMLHttpRequest, но с некоторыми изменениями. XHR2 является неотъемлемой частью сложных веб-приложений, поэтому ему стоит уделить большее внимание.

Наш старый друг XMLHttpRequest сильно изменился, но не многие знают о его изменениях. XMLHttpRequest Level 2 включает в себя новые возможности, которые положат конец нашим безумным хакам и пляскам с бубном вокруг XMLHttpRequest: кросс-доменные запросы, процесс загрузки файлов, загрузка и отправка двоичных данных. Эти возможности позволяют AJAX уверенно работать без каких-либо хаков с новейшими технологиями HTML5: File System API, Web Audio API, и WebGL.

В этой статье будут освещены новые возможности XMLHttpRequest, особенно те, которые можно использовать при работе с файлами.

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

Привет, Хабр. Не так давно мне на глаза попалась статья в TheHostingNews.com, в которой редакторы сайта сравнили две наиболее популярные за рубежом панели управления хостингом – cPanel и Parallels Plesk Panel. Я решился на перевод этой статьи по двум причинам. Во-первых, в ней отсутствует предвзятость, особенности каждого продукта переданы максимально корректно. Во-вторых, в Рунете полноценных обзоров хостинг-панелей мне видеть не приходилось: видимо, у нас принято обсуждать какие-то конкретные «болячки» или преимущества того или иного решения, не особо обращая внимание на продукт в целом.

Делая перевод, я пытался обратить особое внимание на какие-то детали обоих продуктов, принципиально важные с точки зрения хостеров. Буду рад, если текст и таблицы будут полезными сообществу.

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