Как и многие другие истории создания бизнеса – моя история, тоже началась, когда у меня -лопнуло терпение принимать «правила игры» от недалеких руководителей и чиновников, и слепо идти по жизни, навстречу судьбе.
Итак, на дворе — ноябрь 2005 года. Начало эры «углеводородной лихорадки». За моими плечами остались многие годы работы в структуре коммерческих отделов алкогольных компаний и ликеро-водочных заводов. А десятки выставок и командировок по городам нашей Родины — помогли накопить опыт, который в будущем — оказался для меня бесценным!

Автоматизация тестирования.

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

В данной статье я постараюсь детально рассказать о работе с Coded UI Test, одним из множества нововведений Visual Studio 2010, а так же упомянуть о проблемах, с которыми я столкнулся.

Не будем зря терять время и сразу приступим к тестированию.

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

Учиться учиться? Кому нужна учеба в современном ВУЗе, мой эксперимент длинной в год в одном из Харьковских ВУЗов.

Проблема

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

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

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

   Вчера я писал про то, что компания Intel представила на интереснейшей международной компьютерной выставке, а сегодня – пара слов о том, чем порадовала общественность компания ASUS.


Много всего вкусного под катом :)

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

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

Знаете, в чем на самом деле фишка? В разности целей!

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

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

Вступление

Я уже довольно давно читаю Хабр, и много раз видел посты про тайм-менеджмент и про то, как «улучшить свою жизнь за 5 минут». Так случилось, что около полутора лет назад я и сам заинтересовался тайм-менеджментом, и с тех пор постоянно испытываю разные методики в надежде скомпилировать нечто своё, полностью удовлетворяющее моим потребностям. Пару месяцев назад я в очередной раз пересмотрел свой подход к управлению временем, и, кажется, нашёл нечто, асимптотически стремящееся к идеалу :). Именно этой методикой я и хочу поделиться с уважаемыми хабраюзерами в надежде на то, что кто-нибудь сможет почерпнуть из неё что-то полезное.

Как правило, при написании .NET программ используются не только классы из .NET BCL, но и сторонние библиотеки. Во время выполнения программы все используемые библиотеки должны быть найдены. Для этого зависимые dll кладут в одну папку с exe файлом.

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

В статье рассказывается, как создавать такие автономные программы из одного файла. Разобран пример как со сжатием зашить библиотеку AutoMapper в программу и как ее потом достать и использовать.

Недавно я попал на новый проект, с задачей создать небольшое приложение с нуля. Разговариваю с тестером:
— А как тебе новые версии поставлять?
— Можешь как все остальные на проекте, через SVN.
— То-есть ты сама билдить будешь?
— Да нет… Бинарники оттуда беру.

Оказывается, очень много программистов, даже имеющих в подписях слова вроде Senior или Superior никогда в жизни не стыкались с понятием CI, или слабо себе представляют что это такое. Не найдя отдельных публикаций на Хабре на эту тему, решил восполнить пробел, а заодно и по возможности заработать желанный инвайт.

1. Анонимные чаты: omegle.com, chatroulette.com
2. Сайты-помощники: kwiz.me, kimir.org, englishtips.org
3. Подкастинг: eslpod.com, effortlessenglish.com, npr.podcast.com, businessenglishpod.com,
4. Качаем фильмы/сериалы, затем субтитры к ним. Просматривать можно с замедлением в VLC плеере чтобы лучше переваривать. Еще рекомендую комик шоу, например Important Things with Demetri Martin — не пожалеете.
5. В скайпе ищем каких нибудь индусов со статусом SkypeMe и не стенсняясь знакомимся.
6. При прочтении какой-то книги или просмотра фильма неплохо бы подготовится таким образом: берем текст, устанавливаем длину слова и частоту употребления в тексте и запускаем, например, этот скрипт (PHP): pastebin.com/m7672c2a9
В итоге имеем дайджест слов большинство из которых вы уже знаете но остальные стоит подучить. И когда вы будете смотреть фильм или читать книгу вы автоматом поймете это слово.
7. Произношение слов — ставим в Google.translate режим Русский->English и в поле текста пишем английское слово — оно без перевода встанет справа вместе с флэшкой которое произносит слово. Также forvo.com, howjsay.com
8. Социальные сервисы ответов:
answers.yahoo.com, vark.com
9. Социальные сети для изучения языка:
livemocha.com, lingq.com, italki.com
10. Остальное:
nytimes.com, ecenglish.com, urbandictionary.com
allengl.narod.ru/top/phvTOP170.htm

Надеюсь каждый нашел для себя что-то полезное:)

Сообщество MSUG объявило о веселом конкурсе. Вы придумываете и присылаете анекдоты или шутки в формате программного кода или сказки, притчи и басни на ИТ тематику. Это могут быть видео и аудио варианты вашего творчества или стихотворения в стиле Крылова — выбор за вами!

Публиковать свои произведения альтернативного искусства можно в твиттере: анекдот-код с тегом #codejoke, басни/притчи — #itfairytale, на форуме или прямо в комментариях.

Нет никаких ограничение в выборе языка программирования для #codejoke. Для затравки:



Авторы лучших #codejoke и #itfairytale получат лицензированную Windows 7 Ultimate!

Кроме того, мы разыграем купоны со скидками для сдачи сертифицированных экзаменов, предоставим участникам доступ к оригинальным электронным книгам по последним технологиям Microsoft.

Читая блог Ивана Сагалаева нашел отсылку на статью показавшуюся мне интересной и достойной перевода.

Лифты, поезда и Информационные технологии

Возможные методы для создания безопасных систем.

Джордж Вестингауз не был теоретиком, а одним из великих изобретателей 19 века. Возможно, самым известным его изобретением был воздушный тормоз для поезда в 1869. Чуть позже подробнее.

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

Ровно четыре месяца как мы находимся в самостоятельном плавании по волнам собственного бизнеса. Мы как никогда чувствуем себя «в седле» и испытываем огромный душевный подъем. Однако есть сложности, которые приходится преодолевать стартаперу; о них и о своем личном опыте я и хочу поведать.

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

Миф 1. Я создам свое дело и буду полностью свободен.

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

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

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

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

Вообще говоря, программистам относительно повезло: работа не пыльная, интересная, платят не плохо, и на хабре можно походу посидеть… :)

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

Привет всем. Основываясь на предыдущем опыте, считаю нужным сразу расставить все точи над ё. Описанная ниже методика — не мое изобретение. Однако из собственного опыта могу уверить вас, что она работает. Ровно так, как обещано.
Идея, описанная в посте, появилась давно (под катом есть история), в том виде, в каком расскажу ее я, по большей части она представлена в чудесных книгах Тони Бузана Use You Head и The Speed Reading Book (в последней много воды).

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

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

Прежде чем приступить к самому главному, прошу вас пройти тест из шести вопросов на Да/Нет.

1. Чтение со скоростью свыше 1000 слов в минуту невозможно?
2. Медленная скорость чтения способствует лучшему пониманию текста?
3. Пропускать слова во время чтения — плохая привычка, ухудшающая понимание текста?
4. По умолчанию мы все читаем с «естественной» для нас скоростью, а следовательно, наилучшей?
5. Если вы не поняли слово или предложение, лучше перечитать его и понять?
6. Ваши глаза находятся в непрерывном движении во время чтения?
За результатами и, наконец-то, интересными штуками добро пожаловать под кат.