Nokia довольно давно появилась на рынке планшетов. В 2007 году, за несколько лет до появления iPad, у них уже был интернет-планшет N800 (который, правда, по современным меркам больше похож на фаблет [phablet — нечто среднее между планшетом и смартфоном, устройство с диагональю порядка 5-7 дюймов, например Samsung Galaxy Note — прим.пер.]). Конечно, на настоящий момент Nokia не производит планшетов, однако, если судить по замечаниям CEO Nokia Стивена Элопа (Stephen Elop), который намекнул, что компания хочет вернуться в эту область рынка, вскоре ситуация может измениться.
Рубрика «переводы» - 41
Nokia рассматривает возможность производства планшетов
2013-02-05 в 9:30, admin, рубрики: nokia, переводы, планшеты, Смартфоны и коммуникаторыКак и чему учиться у конкурентов
2013-02-05 в 5:14, admin, рубрики: конкурентная разведка, конкурентные преимущества, конкуренция, переводы, продуктовая разработка, управление проектами«Попался. Предатель. Ржунимагу». Как-то так реагируют люди, узнав, что у меня iPhone. И вот стою я перед вами, уличенный в пользовании продуктом конкурента — и признаю себя виновным.
Но, если отложить в сторону блогеров с их постами в духе «попался», на деле есть реальные причины для того, чтобы пользоваться продуктами/сервисами помимо тех, что сделаны вами (или компанией, где вы когда-то работали). Можно написать хоть тысячу твитов, но, думаю, это всё равно все знают. Подход, применяемый во многих отраслях — недооценивать или даже чураться конкуренции — подробно описан и изучен, и выводы, к которым он приводит, говорят о том, что конкуренция это хорошо.
Способность учиться у конкурентов не только необходимо развить у всей команды разработчиков продукта, но она также может быть своего рода навыком, который имеет смысл оттачивать. Давайте в деталях рассмотрим всё, что касается использования продуктов конкурентов.
Читать полностью »
Обзор инструментов для сжатия изображений
2013-02-04 в 13:22, admin, рубрики: Веб-разработка, обработка изображений, переводы, метки: Веб-разработка, обработка изображений 
Для ускорения сайта, некоторые рекомендуют проанализировать каждую страницу: оптимизировать запросы HTTP и любые перенаправления, сжать скрипты и стили и т. д. Все это без сомнения необходимо, но в первую очередь важно рассмотреть основы. В частности, вы уверены, что любая графика, которую вы используете на создаваемых сайтах, полностью оптимизирована для Интернета?
Читать полностью »
Обучение через обмен наблюдениями
2013-02-04 в 6:35, admin, рубрики: командная работа, обмен опытом, переводы, продуктовая разработка, управление командой, управление проектами, Управление проектомВ продолжении перевода первой статьи Стивена Синофски о продуктовой разработке — перевод его второй статьи, про важность обмена опытом в команде, разрабатывающей продукт.
Обмен сырой информацией — важная составляющая создания сильной сплоченной команды. Это дает возможность каждому видеть входные данные и на их основе делать свои выводы, будь то новые планы или смена курса в уже существующих.
В этом посте я делюсь некоторыми мыслями и опытом о том, как составлять отчет о поездках в контексте разработки продуктов.
Зачем делать отчеты о поездках?
С самого начала моих командировок моим менеджерам всегда требовались отчеты о поездке в обмен на возможность куда-то съездить за счет компании. Независимо от того, менеджер вы или нет, поделиться новой информацией и вашими наблюдениями, полученными за время поездки (будь то посещение объекта, круглый стол для потребителей, выставка или конференция) — это способ внести свой вклад в общее понимание продуктов и технологий.
Отчет, это всего-то — набор слов и материалов, это далеко не список дальнейших действий, поскольку их можно сформулировать лишь, собрав данные с разных точек зрения и обдумав все последствия. На самом деле, ошибочно при разработке продукта тотчас кидаться воплощать все соображения, которые кто-то «привез» из одной из командировок или же чью-либо личную точку зрения (и не важно, кто из команды написал этот отчет). Это всего лишь рассказ, и чтобы превратить его в конкретные шаги — смену плана или изменение состава возможностей — нужна отдельная работа.
Подходы
Не существует «правильного» способа составления отчета. Чаще всего его формат, структура и детали должны определяться тем, что это за событие: выстраиваете ли вы структуру по типам технологий или поставщику, по потребителям или темам потребителей, по сессиям конференции, по техническим подсистемам или как-то еще?
Читать полностью »
Интервью с создателем C++ STL, 1995 г. Часть 3
2013-02-01 в 11:04, admin, рубрики: c++, stl, История ИТ, обобщённое программирование, переводыЗавершающая часть перевода интервью (первая часть, вторая часть), взятого у создателя Стандартной библиотеки шаблонов Алекса Степанова в 1995 году. Здесь Алекс рассказывает о том, почему в шаблонах не включена поддержка персистентности и серилазизации, о будущем библиотеки и о связи ООП и обобщённого программирования.
Алекс, STL не реализует объектную модель персистентности (постоянного хранения) объектов. Map и Multimap являются особенно хорошими кандидатами для постоянного хранения контейнеров как инвертированных индексов в базах данных постоянного хранения объектов. Скажите, работали ли Вы в этом направлении или же Вы можете хотя бы прокомментировать реализации этой идеи?
Это обстоятельство отмечалось многими. STL не реализует персистентность по уважительной причине. STL настолько велика, насколько можно было себе представить в то время. Я не думаю, что любой больший набор компонентов прошёл бы через Комитет по стандартам. Но персистентность является тем, о чём думали некоторые люди тогда. При проектировании STL и особенно во время проектирования компонента-распределителя, Бьярн отметил, что распределители, которые инкапсулируют памяти модели, могут быть использованы для инкапсуляции модели постоянной памяти. Прозрение принадлежит Бьярну, и это важное и интересное прозрение. Несколько компаний, разрабатывающие объектные базы данных, рассматривают эту идею. В октябре 1994 года я посетил встречу Группы по системам управления объектными базами данных. Я выступил с докладом по STL, и после был большой интерес к тому, чтобы сделать контейнеры с их развивающимся интерфейсом соответствующими STL. Они не рассматривали распределители как таковые. Некоторые из членов группы, однако, пытались выяснить, могут ли распределители быть использованы для реализации персистентности. Я ожидаю, что в течение следующего года появятся хранилища объектов с STL-совместимыми интерфейсами, которые будут вписываться в рамки STL.
Читать полностью »
Доставка — или «быстрейший способ обанкротиться на Kickstarter»
2013-01-31 в 19:40, admin, рубрики: краудфандинг, Крауфандинг, логистика, переводы, метки: Крауфандинг, логистика, переводы В последнее время быстро набирает обороты явление, именуюмое в России странным словом Крауфандинг. Хочу обратить внимание уважаемых читателей на один из аспектов, который редко рассматривается при обсуждении его возможностей для стартапа Вашего проекта. Это логистика. Как и множество других подводных камней, недооценка данного фактора на стадии расчёта предварительной стоимости лотов может привести к убыточности проекта, который успешно собрал средства на площадке Kickstarterа.
Если Вы задумываетесь о запуске своего проекта, то это статья о чужом печальном опыте и тонкостях почтовых отправлений в США несомненно для Вас. Многим другим тоже может быть интересно.
И так представляю перевод свежего поста Эриком Дэльмана от 28 января 2013 года о проекте создания игральных карт.
Читать полностью »
Как технологии и общественные науки помогают планировать
2013-01-31 в 10:45, admin, рубрики: переводы, планирование, продуктовая разработка, управление проектами, Управление проектом Не так давно Стивен Синофски (экс-вице-президент подразделения Windows в Microsoft) начал вести свой блог, в котором он делится мыслями о продуктах, продуктовой разработке и управлении.
Мы с любезного разрешения автора решили заняться переводом его статей. Представляем вашему вниманию перевод первой статьи из этой серии.
Одна из масштабных проблем в создании технологичных продуктов заключается в том, что для вывода продукта или услуги на рынок нужно, чтобы блестящие инженеры добились блестящих результатов — при этом они не могут знать, приведет ли их выбор к успеху или провалу. Это кажется очевидным, но часто такая загвоздка – главный виновник напряжения в команде разработчиков или просто любой группе.
Примечание: Говоря «инженер», под этим мы подразумеваем все специализированные навыки, необходимые для создания продукта, включая разработку, тестирование, дизайн и прочее. Более того, под «продажами» или «маркетингом» мы имеем в виду все специализированные умения, которые требуются для передачи продукта клиентам и его поддержки — это целый спектр навыков и обязанностей, которые крайне важны. Независимо от того, сколько существует специализаций, границы между ролями всегда нечеткие — и это хорошо.
Естественное напряжение (sic!)
Каждый не-инженер, который хоть раз общался с инженером, знает как сложно (или неприятно) выслушивать, что «что-то возможно, а что-то — нет», или что «это правильно, то бессмысленно, а вот это — глупее некуда». Точно так же и каждому инженеру знакомы неприятности в общении со специалистом по продажам, продавцом, или потребителем, который настаивает на том, что «делать нужно именно так», но не может хоть сколь-нибудь разумно объяснить, почему. Это обычно называют «естественным напряжением» или «организованный баланс сил», влияющих на команду.
Но кому нужно это «организованное напряжение»? Даже когда вы просто делаете, то что должно, вам и без того хватает стресса — зачем добавлять новый, от которого к тому же никак нельзя будет избавиться?
Справиться с этим непросто. Конечно, можно отправить инженеров к потребителям или же заставить «продажников» сидеть на совещаниях по архитектуре, но это смешно и никак не влияет на указанные проблемы и обстоятельства каждой из сторон. На самом деле, простого решения нет, поскольку реальность основана на опыте, культуре, а иногда и временных рамках для разных членов команды разработчиков. Чем принимать естественное напряжение как нечто неизбежное, полагаться на байки или пытаться совместить ДНК команды, можно найти более верный подход.
Читать полностью »
Мы — Гики: Лучшие научные петиции на проекте Белого Дома «Мы — Народ»
2013-01-29 в 14:45, admin, рубрики: ddos-атака, Аарон Шварц, будущее здесь, гики, космос, мракобесие, нло, Обама, переводы, пиво, США Администрация Обамы не поддерживает взрыв планет (о чем уже писал Zelenyikot). Устроила выходной для федеральных государственных служащих в Рождественский сочельник. Не будет устраивать импичмент президенту Обаме или распределять оборонные средства в пользу NASA.
Но тем не менее, Белый Дом поделится своим фирменным рецептом домашнего пива — он не засекречен. И они им поделились. Все, что нужно было для этого сделать — просто спросить и 12240 человек это сделали приняв участие в программе подачи петиций Белого Дома «Мы — Народ».
Читать полностью »
Китайский геймер убил двоих и сжег дом из-за отключения интернета
2013-01-28 в 4:06, admin, рубрики: Игровые приставки, игры, интернет, китай, китайцы, переводы, разрыв соединения 
Фотография из оригинальной новости
Инцидент произошел в интернет-кафе, когда между клиентом и хозяином заведения вспыхнула ссора из-за разрыва соединения. Разъяренный клиент зарезал хозяина ножницами и забил насмерть молотком его жену, а затем поджег здание.
Полиция города Жэньцю (провинция Хэбэй) арестовала убийцу только в начале этого месяца, хотя само происшествие случилось в декабре. Тогда геймер по фамилии Чжао пришел в интернет-кафе, где играл в онлайн-игры с 6 вечера. В районе 10 часов интернет в салоне неожиданно отключился. Чжао позвал хозяина заведения по фамилии Жэнь выяснить причины разрыва. Жэнь объяснил причины тем, что Чжао скачал вирус, который нарушил работу сети.
Интервью с создателем C++ STL, 1995 г. Часть 2
2013-01-27 в 11:11, admin, рубрики: c++, stl, История ИТ, обобщённое программирование, переводыПродолжение первой части перевода интервью, взятого у создателя Стандартной библиотеки шаблонов Алекса Степанова в 1995 году. В этой части Алекс рассуждает о том, почему шаблоны устроены именно так и почему они хороши. Также описана весьма захватывающая история о том, как удалось внести STL в Стандарт.
Алекс, где и когда вы решили предложить STL как часть определения ANSI/ISO Стандарта C++?
В течение лета 1993 г., Эндрю Кёниг посещал Стэнфорд для преподавания курса C++. Я показал ему кое-что из наших материалов, и, я думаю, он был искренне захвачен увиденным. Он организовал приглашение для меня в качестве докладчика на ноябрьской встрече Комитета по Стандарту C++ в Сан-Хосе. Я прочитал доклад, обозначенный как «Наука программирования на C++». Моя речь была скорее теоретическая. Основная позиция заключалась в том, что существуют фундаментальные законы, которые связывают очень примитивные операции, такие как конструкторы, присваивание и равенство. C++ как язык не навязывает никаких ограничений. Вы можете определить собственный оператор равенства для того, чтобы выполнить умножение. Но равенство должно быть равенством, и оно должно быть рефлексивной операцией. A должно быть равно A. Оно должно быть симметричным. Если A равно B, то B равно A. A должно быть транзитивным. Обычные математические аксиомы. Равенство присуще другим операциям. Имеются аксиомы, связывающие конструктор и равенство. Если вы конструируете объект с копирующим конструктором из другого объекта, то два объекта должны быть равны. C++ не обязывает к этому, но это один из основных законов, которому мы должны подчиниться. Присваивание должно создавать одинаковые объекты. Т.о., я представил группу аксиом, которые связаны с этими основными операциями. Я немного говорил об аксиомах итераторов и показал некоторые обобщенные алгоритмы, обрабатывающие итераторы. Это была двухчасовая лекция и, я думаю, весьма сухая. Однако она была очень хорошо принята. В то время я не думал об использовании этой штуки в качестве части стандарта, т.к. обычно воспринималось, что это была некая продвинутая техника программирования, которая не стала бы широко использоваться в «реальном мире». Я думал, что у практичных людей не было никакого интереса к любой из этих работ.
Читать полностью »