Например, phonegap не дает никакого графического интерфейса (все нужно делать на html5 и css3), с одной стороны это как бы преимущество с другой стороны имеем проблемы.
1. Пользователь хочет и ожидает увидtть стандартный интерфейс ios или android (а они отличаются и довольно сильно), а получает, что-то другое и это что-то зачастую ему не нравится (да просто потому что другое).
2. Пытаемся имитировать стандартный интерфейс. Теряем в «кроссплатформености» интерфейса (у нас на адроиде будет айфоновсrий интерфейс или наоборот). Зачастую получаем тормозное приложение, которое все называют жалким подобием нативного.
3. Быстрее таки делать интерфейс стандартными контролами, да и проектировать его тоже.
Еще забыли про Sencha Touch 2 упомянуть. Хотя может не совсем в тему, т.к. этот фреймворк не дает api к девайсу, но дает стандартные контролы (как в ext js) для разработки мобильных приложений на javascript и кстати все это очень неплохо работает. Зачастую скрешивают Sencha Touch c phonegap
По моему большинство претензий высосаны из пальца.
Да это не Oracle :)
В запросе есть OR, а также поиск жертв с именем Mari и Magda. Так что если нет жертв с инициалами RL, то их просто нет.
6. Замыкание многих процессов на самых компетентных и перегрузка их работой.
Проблема действительно серьезная.
Решение на мой взгляд такое:
Нужно работать с людьми, которые хотят это делать хорошо.
1. Нужно мотивировать профессионалов. Нужно создавать атмосферу, в которой приятно развиваться как профессионал и делать свою работу. Нужно искать в работе новое. Открывать горизонты. Сейчас скажут — мы не выбираем проекты, у нас все проекты говно и т.п. Могу сказать одно — любую работу можно сделать плохо, посредственно, хорошо и великолепно. Стремится нужно к последнему.
2. Есть люди, с которыми просто не по пути. Расставание всегда означает новые встречи. Не сидите на месте когда тошно, дайте шанс себе и работодателю — либо измените отношение либо увольтесь. То же самое с работодателями — либо менять отношение либо увольнять.
Хорошо работать невозможно заставить, можно только мотивировать.
4. Учет изменений на проекте и документация особенностей.
По этому вопросу я считаю следующее:
— Лучшая документация для программиста это корректно работающий код, который хорошо спроектирован и прокомментирован.
— Лучшая документация для QA это актуальный набор test cases.
— Документы по архитектуре системы, по настройкам, описание процессов деплоймента, процесса разарботки должны быть общедоступными и актуальными.
— Проект должен иметь централизованный архив документов.
— Проект дожен иметь историю итераций четко отраженную в исходном коде — ( допустим в свн для каждого релиза отдельная ветка, коммиты в свн должны быть с комментариями, комитить нужно не часы работы, а законченный куски кода)
При соблюдении этих правил по моему опыту редактировать объемное ТЗ не нужно, достаточно иметь все в архиве. Также при таком подходе вся команда — программисты, тестировщики, менеджеры, заказчики — участвует в процессе документирования своих знаний о проекте. Нужно настраивать процессы.
Еще появилось пару модификаций внутренней библиотеки. В планах построить её разработку (даже скорее просто поплнение) по типу разработки опенсорс проекта.
Опять же с нуля никто ничего не будет разарбатывать, каждый сам за себя. Чтобы получить систееу, нужно сначала создать её, а потом заставить других в неё поверить.
По 10 пункту мы так решаем.
1. Сделали ставки на несколько опенсорс платформ: фреймворк и пару специфичных цмс.
2. На базе это фреймворка разработали собственную библиотеку, которая ускоряет разработку.
3. Фреймворк и библиотека заставляют использовать определенные стандарты кодирования.
Причем это не только оформление синтаксиса кода, а и стандарты проектирования системы.
4. Если есть время каждый новый программист выполняет тестовый проект, в котором использует наработки.
Потом происходит разбор кода.
5. Сделали обучающее видео :)
В процессе — система еженедельных семинаров на интересные темы. 2 часа в неделю найти можно.
Да, но 36 млн рублей это $1 млн 100 тыс. американских долларов. Я конечно не видел ТЗ это веб портала, но 5-й части (пускай 4-й) от этой суммы хватит для разработки очень даже неплохого веб сайта для мин. обороны, с переводом на эти прямо скажем сложные для мультиязычности языки (сюда еще иврита не хватает или японского иероглифами). Железо входит в сумму, но даже если и нет думаю, что оно будет стоить остаток суммы.
Это очередная игра в «откаты». Похоже единственная игра, которую они реализовали. Вот про Систематику статья в Вики. Если это они, то их профиль вообще не игровой. Зато поставки есть комплексные поставки оборудования Мин. финансов.
Интересно еще то, что по идее за БПЛА должен наблюдать оператор в центре управления. Как минимум снижение и посадку они должны были заметить. Опять же отклонение от заданного курса. Даже если он шел на полном автопилоте, уверен какое-то наблюдение должно было быть… или теперь будет :)
Это тест для среднего американца. Можно похожий составить для среднего японца или русского.
Национальность имеет большое значение, потому как в тестах есть культурные стереотипы.
Например, они рассчитаны на то, что человек знает школьную программу. А она то везде разная.
Такие приколы больше всего заметны во всяких тестах. Тех же IQ.
Попробуйте проанализировать несколько школьных учебников по математике.
Например российских и американских.
Это еще раз доказывает, что нельзя одной линейкой мерять похожие, но разные вещи.
Хорошая статья, но она по сути не является ответом на «Programming Sucks! Or At Least, It Ought To» :-)
Вернее ответ разве что на название статьи (да, оно кричит, как и должно название статьи).
Разработка прикладных программ это не только написание хорошего кода, проектирование и написание кода — 50% работы (если ты не новичок), основное услилие тратится на понимание бизнес-логики и создание полезного приложения. Я вообще считаю, что тем и интересно прикладное программирование — каждый проект приносит что-то из своей сферы. На приложение программист должен по разному, как программист и смотреть глазами пользователя, для этого нужно его понять.
И часто приходится видеть проблему, когда код пишется ради кода, это как искусство ради искусства.
Задача прикладного программиста не написать код, а помочь непрограммисту решить его задачу и сделать это наилучшим образом и вовремя :-).
20 штук баксов??
Так в Харькове столько же примерно, самая дешевая я встречал 18 тыс.
Нормальная одиночка 25-30 (средний район, или метро не далеко или много транспорта другого).
А в деревнях не хватает молодежи… :-) (шутка) Не только в Москве такое, практически в любом более менее крупном городе, может разве, что шансов на 1-комнатное жилье больше, но тоже для 80% это нереально.
У facebook было изначально приложение на html5, которое Цукерберг закрыл и назвал наибольшей ошибкой.
www.businessinsider.com/mark-zuckerberg-html5-mobile-2012-9
Сейчас конечно спорят с его словами
www.theregister.co.uk/2012/09/14/facebook_html_5_vs_native_apps/
но суть остается в том, что не все так просто.
Например, phonegap не дает никакого графического интерфейса (все нужно делать на html5 и css3), с одной стороны это как бы преимущество с другой стороны имеем проблемы.
1. Пользователь хочет и ожидает увидtть стандартный интерфейс ios или android (а они отличаются и довольно сильно), а получает, что-то другое и это что-то зачастую ему не нравится (да просто потому что другое).
2. Пытаемся имитировать стандартный интерфейс. Теряем в «кроссплатформености» интерфейса (у нас на адроиде будет айфоновсrий интерфейс или наоборот). Зачастую получаем тормозное приложение, которое все называют жалким подобием нативного.
3. Быстрее таки делать интерфейс стандартными контролами, да и проектировать его тоже.
Еще забыли про Sencha Touch 2 упомянуть. Хотя может не совсем в тему, т.к. этот фреймворк не дает api к девайсу, но дает стандартные контролы (как в ext js) для разработки мобильных приложений на javascript и кстати все это очень неплохо работает. Зачастую скрешивают Sencha Touch c phonegap
Да это не Oracle :)
В запросе есть OR, а также поиск жертв с именем Mari и Magda. Так что если нет жертв с инициалами RL, то их просто нет.
Проблема действительно серьезная.
Решение на мой взгляд такое:
Нужно работать с людьми, которые хотят это делать хорошо.
1. Нужно мотивировать профессионалов. Нужно создавать атмосферу, в которой приятно развиваться как профессионал и делать свою работу. Нужно искать в работе новое. Открывать горизонты. Сейчас скажут — мы не выбираем проекты, у нас все проекты говно и т.п. Могу сказать одно — любую работу можно сделать плохо, посредственно, хорошо и великолепно. Стремится нужно к последнему.
2. Есть люди, с которыми просто не по пути. Расставание всегда означает новые встречи. Не сидите на месте когда тошно, дайте шанс себе и работодателю — либо измените отношение либо увольтесь. То же самое с работодателями — либо менять отношение либо увольнять.
Хорошо работать невозможно заставить, можно только мотивировать.
По этому вопросу я считаю следующее:
— Лучшая документация для программиста это корректно работающий код, который хорошо спроектирован и прокомментирован.
— Лучшая документация для QA это актуальный набор test cases.
— Документы по архитектуре системы, по настройкам, описание процессов деплоймента, процесса разарботки должны быть общедоступными и актуальными.
— Проект должен иметь централизованный архив документов.
— Проект дожен иметь историю итераций четко отраженную в исходном коде — ( допустим в свн для каждого релиза отдельная ветка, коммиты в свн должны быть с комментариями, комитить нужно не часы работы, а законченный куски кода)
При соблюдении этих правил по моему опыту редактировать объемное ТЗ не нужно, достаточно иметь все в архиве. Также при таком подходе вся команда — программисты, тестировщики, менеджеры, заказчики — участвует в процессе документирования своих знаний о проекте. Нужно настраивать процессы.
Опять же с нуля никто ничего не будет разарбатывать, каждый сам за себя. Чтобы получить систееу, нужно сначала создать её, а потом заставить других в неё поверить.
1. Сделали ставки на несколько опенсорс платформ: фреймворк и пару специфичных цмс.
2. На базе это фреймворка разработали собственную библиотеку, которая ускоряет разработку.
3. Фреймворк и библиотека заставляют использовать определенные стандарты кодирования.
Причем это не только оформление синтаксиса кода, а и стандарты проектирования системы.
4. Если есть время каждый новый программист выполняет тестовый проект, в котором использует наработки.
Потом происходит разбор кода.
5. Сделали обучающее видео :)
В процессе — система еженедельных семинаров на интересные темы. 2 часа в неделю найти можно.
Национальность имеет большое значение, потому как в тестах есть культурные стереотипы.
Например, они рассчитаны на то, что человек знает школьную программу. А она то везде разная.
Такие приколы больше всего заметны во всяких тестах. Тех же IQ.
Попробуйте проанализировать несколько школьных учебников по математике.
Например российских и американских.
Это еще раз доказывает, что нельзя одной линейкой мерять похожие, но разные вещи.
Вернее ответ разве что на название статьи (да, оно кричит, как и должно название статьи).
Разработка прикладных программ это не только написание хорошего кода, проектирование и написание кода — 50% работы (если ты не новичок), основное услилие тратится на понимание бизнес-логики и создание полезного приложения. Я вообще считаю, что тем и интересно прикладное программирование — каждый проект приносит что-то из своей сферы. На приложение программист должен по разному, как программист и смотреть глазами пользователя, для этого нужно его понять.
И часто приходится видеть проблему, когда код пишется ради кода, это как искусство ради искусства.
Задача прикладного программиста не написать код, а помочь непрограммисту решить его задачу и сделать это наилучшим образом и вовремя :-).
Так в Харькове столько же примерно, самая дешевая я встречал 18 тыс.
Нормальная одиночка 25-30 (средний район, или метро не далеко или много транспорта другого).
По телефону тяжело, часто много деталей, а по логам точно не забудешь.