От режима зависит. Если с энергосбережением и текстом (или серфинг) то я до 7 часов работал. На полной выкладке часа 4 держит. В общем я думаю где-то на одном уровне.
Пишу с zenbook asus prime. При аналогичной цене и железе, асус более ярко металический и судя по описанию выше — тоньше. Да и стоит дешевле, поэтому смысл выхлопа самсунга если честно не понял. Брал 13 дюймов модель пару в августе за 39 000.
Клавиатура для слепого набора работает идеально. Сам компьютер без проблем тягает на себе хоть виндовс, хоть линукс, и даже макос с некоторыми шаманскими плясками, хотя держать прямые установки не вижу смысла все доп. операционки держу под ВМ. Дисплей великолепен, клавиатура лучшее, чем я пользовался на буках за все время. ФулХД рулит при работе с редакторами, так что для программиста машинка самое оно, + малый вес, + довольно вынослив по батарее. Легкий, очень удобно перемещаться хоть по офису, хоть по квартире.
Из минусов — при сниженных оборотах питания (энергосбережение от батареи) есть проблемы с вайфаем, нужно переключаться на полную производительность. Напрягает утопленная клавиатура, туда постоянно набивается какая-то труха и пыль. Эту часть сообщения специально написал нажимая на углы клавиш.
В целом вполне достаточно. Я бы хотел там видеть еще серию от Windows 8, но доброй воли MS видимо пока нет, а так количество и качество вполне устраивает.
Прошел тест. Набрал 121 бал. Я не программист. Особенно умилил вопрос: «кто был первым программистом?». Перед этим аналогично доставлял вопрос в другом тесте: «Кто владеет правами на Wordpress?». Автор не парься, совершенствуй кунг-фу и гни взглядом ложки.
Проблема всех тестов и прочей фигни в том, что они крайне субъективны и отражают лишь личное мнение автора-составителя. Т.е. некий гражданин который писал этот тест считает что ряд людей не программисты. Это нормальное утверждение, нормальный подход и это ровным счетом ничего не значит.
Раздел программирования не заполнен вообще как на мой взгляд.
Добавил бы:
1. Курс лекций «основы программирования» из наших вузов — нужно чтобы определиться что такое циклы, массивы, ветвления. Что такое переменная, чем отличается от константы.
2. Старый добрый Гради Буч
3. Выбираем язык (я бы выбрал сейчас что-то аля Java или C#). Берем книги фор дамиес и вперед. В случае с Си шарп неплохо можно почитать книги издательства самого MS.
+ сюда же я бы на свой вкус добавил еще дискретную математику и прикладную теорию цифровых автоматов.
Дальше, уже имея понимание, выбираем специализацию и качаем узкие скилзы.
На семинаре в Донецке, один из авторов (Сергей Байдачный) позавчера озвучил претензии от УЕФА по поводу логотипа и каких-то еще авторских прав. Опять же по озвученным в среду в Донецке данным из WP7 marketplace приложение должно было быть изъято в течение пары дней, возможно причина недоступности для андроида именно в этом.
Ключевая проблема — как-нибудь. Хомячки при этом начнут бунтовать, разбегаться и вообще редко бывают готовы просто так отдать закрома. Если бы ФБ знал как получить с имеющейся армии пользователей хотя бы 1 доллар в день с каждого, я думаю им бы и IPO был не нужен.
Для примера тот же Blizzard кушает несчастные 12 долларов в месяц с одного игрока (это меньше бакса при сопоставимых как минимум затратах) и прекрасно живет…
ФБ способствует в первую очередь не целевому использованию рабочего времени. А без «газа», который душит может быть очень холодно зимой делать революцию. Хотя кто об этом задумывается…
Стартапам нужны люди творческие. Я бы даже сказал генераторы фантазии, а их уровень профессионализма остается на заднем плане. Вызвано все это тем, что стартапу не нужен по большому счету продукт, как абсолютно верно замечено в статье задача стартапа отжать 10 лямов инвестиций у инвестора, а не принести на туже сумму прибыли. Вы мне скажите, что за проект в интернете может стоить 10 миллионов долларов? Инновационные разработки в ИИ или очередная распиареная хомпага с красивыми картинками и псевдоуникальным функционалом? Вот отсюда и проблемы с подбором персонала — стартап бизнес на понтах.
>Внезапки, вроде смены форматов или трудности с доступом к данным случаются. Вопрос в том, что дальше.
Это по большому счету вообще не проблема, это изменение объема работ, просто обе стороны должны отчетливо это понимать и адекватно находить решения сложившейся ситуации. Если допустим заказчик понимает, что неверно сформулировал задачу на этапе постановки, то он должен быть готов к изменению сроков. Если программист видит ошибку в логике заказчика, то он должен сообщить об этом заказчику, иначе в дальнейшем в результате молчания может нажить себе кучу проблем.
Я не говорил, что я крут-крут-крут. Я говорю о том, что если закладывать все риски в срок проекта, то на выходе получится огромный срок, поэтому считается все-таки по среднему. Теперь по пунктам:
1. В начале специально уточнялся вопрос о соответствии формата во всех трех источниках. Более того, с точки зрения заказчика он реально соответствовал, все поля содержали требуемые данные, но… Я думаю нет смысла объяснять на сколько неудобно на этапе консолидации иметь в источниках город Москва, Москва и г. Москва. На взгляд обывателя (коим заказчик и является) все ок. С точки зрения программиста — время на приведение всего к единому виду. Я затрудняюсь определить как подобные вещи можно предусмотреть.
2. Подумали, указали косвенные сроки, вот только снова возвращаемся к восприятию. Заказчик на ифы не смотрит, он видит конечный срок неделя. А на объяснения, что 2 дня с момента получения данных это не 2 дня с момента начала работы в итоге тратится еще час.
3. По этому проекту я лично с заказчиком не контактирую, но по косвенным наблюдениям со стороны заказчика менеджеры будут на порядок опытнее. Почему они в свою очередь не учитывают этот факт, хотя я более чем уверен, что отлично все понимают — загадка.
В общем резюмируя я еще раз повторю суть коллапса:
1. На старте невозможно предусмотреть все риски. Единственным решением является балансировка сроков после каждого меилстоуна.
2. Если пытаться просчитать все временные затраты на старте, то на выходе получится абсолютно космическое число часов.
3. Разработка проекта это диалог между заказчиком и исполнителем, если кто-то уходит в жесткий отказ, то с большой долей вероятности проект погибнет.
4. Еще одна проблема в том, что на разных этапах мы оперируем разной стоимостью изменений. Если послать исполнителя на старте это «дешево», то перебросить проект на кого-то другого на этапе отладки — целое состояние, как по деньгам, так и по времени. Здесь уже приходится искать компромиссы. Причем средства для шантажа друг друга есть и у одной и у другой стороны.
5. Неопытностью можно оправдать любые ошибки, но как правило за каждой конкретной проблемой стоит конкретная ситуация, факты, решения. Поэтому называть это одним понятием «нехватка опыта у менеджера» я бы не стал.
Из минусов — при сниженных оборотах питания (энергосбережение от батареи) есть проблемы с вайфаем, нужно переключаться на полную производительность. Напрягает утопленная клавиатура, туда постоянно набивается какая-то труха и пыль. Эту часть сообщения специально написал нажимая на углы клавиш.
Больше недостатков не замечено.
Проблема всех тестов и прочей фигни в том, что они крайне субъективны и отражают лишь личное мнение автора-составителя. Т.е. некий гражданин который писал этот тест считает что ряд людей не программисты. Это нормальное утверждение, нормальный подход и это ровным счетом ничего не значит.
Добавил бы:
1. Курс лекций «основы программирования» из наших вузов — нужно чтобы определиться что такое циклы, массивы, ветвления. Что такое переменная, чем отличается от константы.
2. Старый добрый Гради Буч
3. Выбираем язык (я бы выбрал сейчас что-то аля Java или C#). Берем книги фор дамиес и вперед. В случае с Си шарп неплохо можно почитать книги издательства самого MS.
+ сюда же я бы на свой вкус добавил еще дискретную математику и прикладную теорию цифровых автоматов.
Дальше, уже имея понимание, выбираем специализацию и качаем узкие скилзы.
Для примера тот же Blizzard кушает несчастные 12 долларов в месяц с одного игрока (это меньше бакса при сопоставимых как минимум затратах) и прекрасно живет…
Это по большому счету вообще не проблема, это изменение объема работ, просто обе стороны должны отчетливо это понимать и адекватно находить решения сложившейся ситуации. Если допустим заказчик понимает, что неверно сформулировал задачу на этапе постановки, то он должен быть готов к изменению сроков. Если программист видит ошибку в логике заказчика, то он должен сообщить об этом заказчику, иначе в дальнейшем в результате молчания может нажить себе кучу проблем.
О статье смотри пункт 5 выше.
1. В начале специально уточнялся вопрос о соответствии формата во всех трех источниках. Более того, с точки зрения заказчика он реально соответствовал, все поля содержали требуемые данные, но… Я думаю нет смысла объяснять на сколько неудобно на этапе консолидации иметь в источниках город Москва, Москва и г. Москва. На взгляд обывателя (коим заказчик и является) все ок. С точки зрения программиста — время на приведение всего к единому виду. Я затрудняюсь определить как подобные вещи можно предусмотреть.
2. Подумали, указали косвенные сроки, вот только снова возвращаемся к восприятию. Заказчик на ифы не смотрит, он видит конечный срок неделя. А на объяснения, что 2 дня с момента получения данных это не 2 дня с момента начала работы в итоге тратится еще час.
3. По этому проекту я лично с заказчиком не контактирую, но по косвенным наблюдениям со стороны заказчика менеджеры будут на порядок опытнее. Почему они в свою очередь не учитывают этот факт, хотя я более чем уверен, что отлично все понимают — загадка.
В общем резюмируя я еще раз повторю суть коллапса:
1. На старте невозможно предусмотреть все риски. Единственным решением является балансировка сроков после каждого меилстоуна.
2. Если пытаться просчитать все временные затраты на старте, то на выходе получится абсолютно космическое число часов.
3. Разработка проекта это диалог между заказчиком и исполнителем, если кто-то уходит в жесткий отказ, то с большой долей вероятности проект погибнет.
4. Еще одна проблема в том, что на разных этапах мы оперируем разной стоимостью изменений. Если послать исполнителя на старте это «дешево», то перебросить проект на кого-то другого на этапе отладки — целое состояние, как по деньгам, так и по времени. Здесь уже приходится искать компромиссы. Причем средства для шантажа друг друга есть и у одной и у другой стороны.
5. Неопытностью можно оправдать любые ошибки, но как правило за каждой конкретной проблемой стоит конкретная ситуация, факты, решения. Поэтому называть это одним понятием «нехватка опыта у менеджера» я бы не стал.
ЗЫ На счет кино +100500