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

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

Автор: Вячеслав Михайлов, Solutions Architect.

В этой статье я поделюсь опытом проектирования RESTful API — на конкретных примерах покажу, как делать хотя бы простые сервисы красиво. Также мы поговорим, что такое API и зачем он нужен, поговорим об основах REST — обсудим, на чем его можно реализовывать; коснемся основных веб-практик, которые зависят и не зависят от этой технологии. Также узнаем, как составлять хорошую документацию, затрачивая на это минимум усилий, и посмотрим, какие существуют способы нумерации версий для RESTful API.

Часть 1. Теория

Итак, как мы все знаем, API — application programming interface (интерфейс программирования приложений), набор правил и механизмов, с помощью которых одно приложение или компонент взаимодействует с другими

Почему хороший API — это важно?

• Простота использования и поддержки. Хороший API просто использовать и поддерживать.
• Хорошая конверсия в среде разработчиков. Если всем нравится ваш API, к вам приходят новые клиенты и пользователи.
• Выше популярность вашего сервиса. Чем больше пользователей API, тем выше популярность вашего сервиса.
• Лучше изоляция компонентов. Чем лучше структура API, тем лучше изоляция компонентов.
• Хорошее впечатление о продукте. API — это как бы UI разработчиков; это то, на что разработчики обращают внимание в первую очередь при встрече с продуктом. Если API кривой, вы как технический эксперт не будете рекомендовать компаниям использовать такой продукт, приобретая что-то стороннее.

Теперь посмотрим, какие бывают виды API.

Виды API по способу реализации:

• Web service APIs
  
  • XML-RPC and JSON-RPC
  • SOAP
  • REST
  
  
• WebSockets APIs
• Library-based APIs
  
  • Java Script
  
  
• Class-based APIs
  
  • C# API
  • Java
  
  

Виды API по категориям применения:

• OS function and routines
  
  • Access to file system
  • Access to user interface
  
  
• Object remoting APIs
  
  • CORBA
  • .Net remoting
  
  
• Hardware APIs
  
  • Video acceleration (OpenCL…)
  • Hard disk drives
  • PCI bus
  • …
  
  

Вчера стала известна информация, что неизвестным хакером были взломaны аккаунты администраторов биржи FL.ru (old Free-lance.ru).

Исследуем аудиторию

Перед каждым автором на Хабре встает вопрос: «В какие же хабы разместить статью»? Безусловно, ответ прежде всего зависит от темы. С другой стороны, многие статьи достаточно широкого профиля и приходится тщательно выбирать в какие три хаба написать. Сам Хабр такого инструментария для анализа не предоставляет. А что делают обитатели хабра, когда инструмент нужен, а его нет? Они его пишут!

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



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

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

^{Мыс Доброй Надежды}

С английским у меня беда. Дело в том, что учил я его по MS-DOS и Паскалю, а потом по фильмам. Поэтому читать и переводить в нашу сторону научился хорошо, а вот строить предложения на лету для разговора – нет. А оно сильно надо, потому что у Мосигры всё больше и больше партнёров в Европе. Думаю, у вас такие проблемы не возникают, но вот желание заправить трактор иногда появляется — и живой английский реально нужен почти каждому.


^{Мой заезд: Швейцария, Эмираты, Германия, Канада, Франция}

Поэтому я недолго думая отправился в Южную Африку. Быстрых по визе вариантов с тёплой погодой было три: Мальта (где среди учеников сплошь китайцы, а сам остров можно обойти за два дня), Дублин (с очень интересным акцентом) и Кейптаун (колония Великобритании). Поэтому – вниз, за экватор, и на самый край обитаемого мира. В Африку, к пушистым слонам и пингвинам, копающим норы.

Пост — резюме

Думаю, начать стоит с того, что в последнее время все больше заказчиков обращаются не только за тестированием на проникновение, но и за проверкой устойчивости их сервисов к атакам на отказ в обслуживании, чаще всего — веб-сайтов. И на нашей практике пока не было ни одного случая, чтобы реальный работающий сайт (не заранее подготовленная площадка) не вышел из строя, в т.ч. находящийся под разными защитными системами. И этот пост — резюмирование текущего опыта (D)DoS тестирования разными методами совершенно разных инфраструктур (от банков до типичных корпоративных сайтов).

Сколько раз вы испытывали проблемы с производительностью SQL Server'а и решали, куда именно смотреть?

Одна из самых редко используемых методологий устранения проблем с производительностью SQL Server'а называется «Ожидания и очереди» (также известная как «статистика ожиданий»). Основная предпосылка методологии состоит в том, что SQL Server постоянно отслеживает, какие потоки выполнения должны ждать. Вы можете запросить у SQL Server'а эту информацию для того чтобы сократить перечень возможных причин проблем с производительностью. «Ожидания» — это то, что отслеживает SQL Server. «Очереди» — это ресурсы, доступ к которым ожидают потоки. Система обычно фиксирует огромное количество ожиданий, и все они означают ожидание доступа к различным ресурсам. Для примера, ожидание PAGEIOLATCH_EX означает, что поток ожидает чтения страницы данных с диска в буферный пул. Ожидание LCK_M_X означает, что поток ожидает возможности наложить эксклюзивную блокировку на что-то.

Отличная новость состоит в том, что SQL Server знает, в чем именно заключаются проблемы с производительностью, и все что вам нужно — это спросить у него… и потом правильно интерпретировать то, что он скажет, что может быть немного сложнее.

От переводчика: Sam Altman, успешный предприниматель из Калифорнии, делится своими наблюдениями по поводу того, что общего у самых успешных компаний. Сам Sam Altman, основавший компанию Loopt, которой удалось привлечь $30 миллионов венчурного капитала, входит в число партнеров Y Combinator. BusinessWeek назвал его одним из «Лучших технологических предпринимателей».

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

* Они одержимы качеством продукта/опыта. Почти слишком одержимы, они тратят много времени на детали, которые на первый взгляд не очень важны. Учредители этих компаний реагируют так, будто они чувствуют физическую боль, когда что-то идет не так с продуктом или пользователю оказывают плохую поддержку. Хотя они верят в ранний запуск и циклы, эти люди не собираются размениваться на плохой продукт. (Это не повод откладывать запуск. Вы, наверное, и так с ним медлите).

Из-за этого они стараются не ставить никого между собой и пользователями. Учредители таких компаний также занимаются продажей и поддержкой самих клиентов.

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

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

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

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

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

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

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

Что делать дальше и на что не забыть обратить внимание.

Сегодня мы завершаем новогоднюю серию постов, посвященных лекциям Школы анализа данных. Последний по порядку, но никак не по важности курс — «Алгоритмы и структуры данных поиска».

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

Мы учли то, о чём нас просили в комментариях к прошлым курсам — теперь при желании можно не только смотреть/скачивать лекции по отдельности, но и загрузить всё разом в виде открытой папки на Яндекс.Диске. Кстати — в предыдущих постах тоже появились такие же апдейты (вот ссылки для удобства: «машинное обучение», «дискретный анализ и теория вероятностей», «параллельные и распределённые вычисления»).



Лекции читает Максим Александрович Бабенко, заместитель директора отделения computer science, ассистент кафедры математической логики и теории алгоритмов механико-математического факультета МГУ им. М. В. Ломоносова, кандидат физико-математических наук.

Почитав 10 простых задач на c# с подвохом я огорчился т.к. по сути своей там и подвохов-то не было особо (этак можно скатиться до "чему будет равно i++ + ++i")… Посему решил немного повспоминать подвохи, которые не хотел бы видеть никогда в жизни 8-). Уровень подготовки middle наверно.

Если спросить у десяти разработчиков о лучшей (или достойной) книге о проектировании, то как минимум 6 из них назовет книгу Боба Мартина «Принципы, паттерны и методики гибкой разработки». Если же после этого показать им на некоторые интересные моменты писанины «дядюшки» Боба, то большая часть из них с недоумением почухает лоб и несколько изменит свое мнение.

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

Спустя три года (!) оно случилось: теперь для того, чтобы платить страховые взносы по сниженной ставке в 14%, нужно иметь 7 сотрудников в штате. Раньше минимальный порог равнялся 30. Пруфлинк на Минкомсвязь России.

Самая важная часть:

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

История

Три года назад, в 2010-м, Дума подготовила изменения в Федеральном законе «О страховых взносах в Пенсионный фонд Российской Федерации, Фонд социального страхования Российской Федерации, Федеральный фонд обязательного медицинского страхования». Суть изменений была прекрасна: для малых ИТ-компаний процент страховых отчислений снижался до 14% вместо стандартных 34%. Загвоздка была в самом определении малых ИТ-компаний, а именно:

• Количество сотрудников компании — не менее 50 (потом снизили до 30, но в корне это ничего не поменяло).
• Доля доходов от реализации ИТ-продуктов и оказания ИТ-услуг — не менее 90%

Со вторым у большинства веб-разработчиков проблем бы не возникло, а вот первое — фактически сводило на нет всю полезность закона. Мы решили пойти в наступление.

Открытые вакансии на должность разработчика в Яндексе есть всегда. Компания развивается, и хороших программистов не хватает постоянно. И претендентов на эти должности тоже хоть отбавляй. Главная сложность – отобрать действительно подходящих кандидатов. И в этом плане Яндекс мало чем отличается от большинства крупных IT-компаний. Так что базовые принципы, описываемые в этой статье, могут быть применимы не только к Яндексу.

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

Доброе утро, Хабр! Нет, сегодня не про вирусы, и даже не про антивирусы. Сегодня про троллей. Патентных. Как вы, возможно, уже слышали, недавно мы («Лаборатория Касперского») задавили еще одного из них — Lodsys. Битва была во всех смыслах эпической: мало того, что само разбирательство длилось аж полтора года, а количество ответчиков превышало 50 штук, так еще и до финиша мы добрались в полном одиночестве, заставив гадину бежать с поля боя, трусливо поджав патенты. Так вот, учитывая, что это была далеко не первая (и не последняя) схватка, можно смело говорить о том, что у нас накопился внушительный опыт в борьбе с патентными троллями разных мастей, размеров и степени наглости. И таким опытом очень хочется поделиться с вами.

Поэтому представляем вашему вниманию 10 основных рекомендаций, которые сформировались во время борьбы с патентными троллями разных стран. Да, у всех есть национальные особенности, но в целом шаблон их действий достаточно однотипен, а приёмчики укладываются в стандарт с небольшими отклонениями. Так что в той или иной степени советы будут полезны любой затролленной компании, не обязательно крупной и не обязательно российской. Вот разве что пост получился немаленький, но мы постарались рассказать обо всем максимально интересно и по существу. Итак…

Техническое собеседование – практически неотъемлемый атрибут трудоустройства любого разработчика, а для старших разработчиков – проведение их (собеседований) ещё и чуть ли не повседневная обязанность. Но как за короткий срок (в идеале 20-30 минут) составить у себя более менее приемлемое представление о реальном опыте соискателя?

Многие современные системы ДБО предоставляют для обслуживания клиентов Web-интерфейс. Преимущества «тонкого клиента» перед «толстым клиентом» очевидны. В то же время существуют федеральные законы, приказы регуляторов и требования к системам ДБО от Банка России, многие из которых касаются именно защиты информации в системах ДБО. Как-то их нужно исполнять и обычно применяются криптосредства, реализующие российские криптоалгоритмы (ГОСТы). Эти криптосредства закрывают часть «дыр», но при их внедрении может существенно возрасти сложность пользования системой ДБО для клиента.

В данной статье мы из «кирпичиков» соберем и испытаем на демонстрационном интернет-банке комплексное решение — по сути специальный переносной защищенный браузер, хранящийся на flash-памяти — в котором будут реализованы закрытие канала (TLS), строгая двухфакторная аутентификация на WEB-ресурсе и электронная подпись платежных поручений посредством USB-токена Рутокен ЭЦП или trustscreen-устройства Рутокен PINPad. Фишка решения в том, что оно абсолютно необременительно для конечного пользователя — подключил токен, запустил браузер и сразу же можно начинать тратить деньги.

TLS, аутентификация и подпись реализуются с использованием российской криптографии.

Дальше пойдет мануал с пояснениями.