Те строки кода с доказательством что трекают не будет? Я так и думал, что хватит только на минуса. А насчет файла журнала вебсервера, так это вообще смешно — потому что можно сказать что трекаеться все в интеренете, при чем здесь соц. сети не ясно.
Ну я же написал что я не зарегистрирован в соцсетях? То что соцсети трекают — это я и без вас знаю, только они трекают в случае если зарегистрирован, но они не трекают ip — если вы мне сейчас будете доказывать обратное — сразу показывайте мне строчку кода где это делается. Так что не надо выдумывает ерунду. Треканье ip идет на уровне сервера приложений/вэб — но не на уровне прикладного уровня сетей.
Или уже не так уже делается? Что-то изменилось в мире?
Не знаю как вы, но я использую в играх для мобил лучший ORM (с поддержкой MongoDB/Membase и кучей других хранилищ данных) Spring Data projects.spring.io/spring-data/
1. Простотота
2. Скорость
3. Отсутвие велосипедов
Если есть время изучать велосипеды с синтаксическим сахором, ради бога. Но я более-менее выбираю «стандарт»
У меня сугубо практический вопрос — а что дает мне, как пользователю, новый браузер? Совсем не праздный вопрос, расскажу «свою историю» — в средине 90-х активно пользовался IE, вариант с NN меня не устраивал — в виду прожорливости последнего (видимо обогнал он время), затем в конце 90-х, в начале 2000х перелез на Оперу, по разным причинам — в основном из-за проблем в IE. С появлением FF отказался от Оперы где-то с 2004 из-за проблем/отсутствием фитч. Если говорит про сегодняшнее время то пользуюсь в основном тремя браузерами на десктопе — FF, Safary, FF+Tor. Избегаю Chrome — потому что не хочу чтоб меня трекал гугл с фейсбуком и парил рекламой. Теперь вот Яндекс. В памяти почему-то всплывает ваш яндекс бар, не получится ли так, что по памяти бар жрет сопоставима, только еще аналитика идет в ФСБ? Где можно посмотреть сравнительные тесты памяти, JS, и поддерживаемых стандартов — чтоб я смог сделать выбор основываясь на каких-то математических критериях, а не на старых каки-то своих страхах из эры яндекс-бара?
Посмотрите, как организовано удаление задач в таск-менеджере Things от Cultured Code. Посвященные удаляют задачи смахиванием влево. Не столь продвинутые нажимают Edit в правом верхнем углу.
Это реализовано для iOS везде, если какой-нибудь программист не запретил стандартный механизм поведения UITableViewController. Вы же сами сказали «Не объясняйте очевидного». На мой взгляд Вы не на том делаете акцент, к сожалению, вот смотрите: есть стандартные инструменты (родные для OS), а есть нестандартные (как по виду так и по поведению). Для стадартных UI все ясно — кнопка нажимаема, чекбоксы отмечаемы, а списки скролятся. А вот с нестандартными проблема всегда — они либо выглядят непривычно, то есть новому пользователю перенести предыдущий опыт работы с другим приложением невозможно по причине неочевидности поведения велосипеда. Либо отходят от привычных iOS паттернов (Mobile User Interface Patterns)
Я бы вообще не пытался объединить мобайл с вебом — как вы это сделали вначале (не говоря уже о вашей попытке объяснять почему в офисном пакете MS Office или scada-систем нет чего-то там — господа, упомянутым системам учат на специализированных курсах и не одну неделю, а по таким пакетам как например SAP можно вообще диссеры писать, там офисный интерфейс как ребенок выглядит)
Более того, я бы дальше пошел. ограничив еще больше предлагаемый материал для статьи списком всего лишь мобильных приложений только для iOS (https://developer.apple.com/library/ios/documentation/userexperience/conceptual/mobilehig/ )- потому есть еще например Android и WP8 у которого есть физические кнопки (контекстного меню и назад) и есть еще игры — а там «ваш» подход вообще не применим, совершенно. В играх все по-другому, начиная от прелодера с Tips и заканчивая Tutorial с объяснениями гестур на основные функции геймплея. Ну у вас как-то размыто и одновременно ни о чем.
Менеджер значительно более заметен большим боссам, успех проекта — его успех. А вот факап проекта в больших корпорациях, это как правило факап исполнителей
Насколько это распространенное явление? Кто может подтвердить, и еще к автору вопрос — с чем это связанно, то что вина лежит о провале на подчиненных Я имею ввиду причины этого, я например думал что как в спорте — за провал турнира несет ответственность главный тренер, как правило аргумент прост — он собирал этих исполнителей и он ими руководил, и как правило, за провалом — идет отставка. И не только в спорте, везде где есть высокая управленческая конкуренция — т.е. когда на твое место дышит в затылок другой.
В том-то и дело, что это ничего не значит, вы смотрите кто действительный владелец — у них офшор на Британских Виргинских островах. Такие схемы так и строят, чтобы запутать — потоки прибыли разделяют и этот подставной питерский офис в действительности чисто номинальный и хозяйственный(сколько у них там в компании написано — 4 человека сотрудников?) выполняет исключительно подрядную роль, а вот что действительно важно — это то что 100% владелец — Doraview Limited, на основании международного права, владельцу гарантируется предотвращение двойного налогообложения. Поэтому они берут НДС, потом им этот НДС возвращают и они его «честно» платят на Британских Виргинских островах в офшоре. :-)
Какие налоги, люди, одумайтесь? У них юрик на Британских Виргинских островах. ))) Какие документы — 2 баксов содержания подставного гендэра и конвертного офиса — вот ИХ ДОКУМЕНТЫ.
Документация проекта и сопровождение проекта, — это две совершенно не согласуемые вещи. Документация пишется почти всегда (кто бы и чтобы не говорил) в таком аврале и в таком урезаном времени, и она может быть:
а)не актуализирована — такое случается наиболее часто в оч. больших проектах(пример то что я видел своими глазами — документация трейдинга крупнейших бирж мира, нарочно пишут ахинею, как было лет 10 назад ) — верить такой документации? У нас одна поверила, уволили, чтоб «глаза разувала чаще».
б)сделана не профессионально. Технические спецы вообще не умеют писать документы и это совсем не преувеличение. 1 на 100 умеет рисовать, 1 на тысячу умеет вставлять таблицы там где нужно структурировать, инфографику вы не найдёте вообще в документации, сделаной программистами. Я уже не говорю про простенькую типографику,- я этих «док», «вик», «спек» насмотрелся раз в 100 больше чем этот «j2ee индус с 8 годами» непонятно где.
в)не согласована. Вот бывает такое есть два документа от двух отделов на одно и то же почти. Один на вики, второй авторизованый pdf. В двух источниках — взаимоисключающая информация. Кому верить?
Какой выход? Думать всегда головой своей. Разбираться в проекте глубоко, ТЩАТЕЛЬНО взвешивать любую входную информацию, АНАЛИЗИРОВАТЬ ее. Потому что люди, которые полагаются на документацию — только потому что «я забрал ее из cvs/svn а дальше меня ничего не интересует», прикрывают сугубо свою собственную задницу(это мое имхо), и по моему опыту работу, им глубоко начхать на проект, для них главное — не взять на себя ответственность.
Начал автор правильно, а в конце, как мне кажется «сдал» — создалось впечатление выдумывал с головы лишь бы дотянуть количество правил до десятки. Я бы немного видоизменил и переформулировал некоторые правила. Например, изменил бы полностью 9 пункт:
9. Никогда не доверяйте документации и тем более не полагайтесь на нее. Этому правилу меня научил мой зав. кафедры xx лет назад. За мою xx летнюю карьеру это правило работало всегда и везде от мелких проектов до крупных, причем даже там, где казалось бы всё должно быть совершенно «по плану». Нифига.
Кроме того я бы изменил 10 пункт, просто потому что он совершенно не работает. Нет, не смотреть чужой код совсем — нельзя, но сформулировать можно и так:
10. Чужой код может ПЛОХОМУ научить. Самое худшее что может к вам привязаться, это чужая плохая привычка. Что я имею ввиду, любой проект всегда имеет какие-то рамки, вы не знаете, что конкретно сподвигло человека писать это и именно это. Обычно люди не пишут в комментариях — «тут ко мне подошел шеф и заставил сократил срок сдачи до завтрашнего утра, поэтому, ув. читатель моего кода, с этого момента качество моего кода немного упадет, так что учтите этот фактор при дальнейшем прочтении». Такое не пишут. По моему опыту, чем опытнее программист, тем больше он ИСПРАВЛЯЕТ в чужом коде, чем его ЧИТАЕТ. Поэтому такое правило, ну вы знаете, на ваш страх и риск.
И последнее. 7 пункт, я бы тоже изменил примерно вот так:
7. Не пугайтесь, но и в тоже время ИЗБЕГАЙТЕ быстрой смены технологий. Потому что с годами понимаешь, это ни к чему не приводит.
В целом с иными пунктами я целиком и полностью согласен с автором.
Интересно куда его теперь экстрадируют? Если в США — это будет конечно цинизм над правосудием. Уж где-где в США он точно сознается и в убийстве Кеннеди и в сотрудничестве с Аль-Каидой.
Только вчера искал на железном рынке LPT для KonicaMinolta древней, во множественных интеренет-магазинах мне сразу любезно ответили, что lpt и 5,25" (это они так стебали меня) дискет у них нет — идите на рынок )
Пошла жара. ) Так я не понял, это Minix был основан на Linux или наоборот? Или может Minix не задумывался как изначально только для обучающих целях? На каком рынке Minix хоть должен был вытеснить? На учебном? Так он и вытеснил его, вводный курс по операционным системах вот уже 20 лет не менялся — изучают архитектуру ОС на примере minix.
Где нынче minix — ты спрашиваешь? А я спрошу лучше, а где нынче Linux нет и почему там Linux нет, может быть тогда какой-то конструктив появится от тебя.
Или уже не так уже делается? Что-то изменилось в мире?
1. Простотота
2. Скорость
3. Отсутвие велосипедов
Если есть время изучать велосипеды с синтаксическим сахором, ради бога. Но я более-менее выбираю «стандарт»
Это реализовано для iOS везде, если какой-нибудь программист не запретил стандартный механизм поведения UITableViewController. Вы же сами сказали «Не объясняйте очевидного». На мой взгляд Вы не на том делаете акцент, к сожалению, вот смотрите: есть стандартные инструменты (родные для OS), а есть нестандартные (как по виду так и по поведению). Для стадартных UI все ясно — кнопка нажимаема, чекбоксы отмечаемы, а списки скролятся. А вот с нестандартными проблема всегда — они либо выглядят непривычно, то есть новому пользователю перенести предыдущий опыт работы с другим приложением невозможно по причине неочевидности поведения велосипеда. Либо отходят от привычных iOS паттернов (Mobile User Interface Patterns)
Я бы вообще не пытался объединить мобайл с вебом — как вы это сделали вначале (не говоря уже о вашей попытке объяснять почему в офисном пакете MS Office или scada-систем нет чего-то там — господа, упомянутым системам учат на специализированных курсах и не одну неделю, а по таким пакетам как например SAP можно вообще диссеры писать, там офисный интерфейс как ребенок выглядит)
Более того, я бы дальше пошел. ограничив еще больше предлагаемый материал для статьи списком всего лишь мобильных приложений только для iOS (https://developer.apple.com/library/ios/documentation/userexperience/conceptual/mobilehig/ )- потому есть еще например Android и WP8 у которого есть физические кнопки (контекстного меню и назад) и есть еще игры — а там «ваш» подход вообще не применим, совершенно. В играх все по-другому, начиная от прелодера с Tips и заканчивая Tutorial с объяснениями гестур на основные функции геймплея. Ну у вас как-то размыто и одновременно ни о чем.
Насколько это распространенное явление? Кто может подтвердить, и еще к автору вопрос — с чем это связанно, то что вина лежит о провале на подчиненных Я имею ввиду причины этого, я например думал что как в спорте — за провал турнира несет ответственность главный тренер, как правило аргумент прост — он собирал этих исполнителей и он ими руководил, и как правило, за провалом — идет отставка. И не только в спорте, везде где есть высокая управленческая конкуренция — т.е. когда на твое место дышит в затылок другой.
а)не актуализирована — такое случается наиболее часто в оч. больших проектах(пример то что я видел своими глазами — документация трейдинга крупнейших бирж мира, нарочно пишут ахинею, как было лет 10 назад ) — верить такой документации? У нас одна поверила, уволили, чтоб «глаза разувала чаще».
б)сделана не профессионально. Технические спецы вообще не умеют писать документы и это совсем не преувеличение. 1 на 100 умеет рисовать, 1 на тысячу умеет вставлять таблицы там где нужно структурировать, инфографику вы не найдёте вообще в документации, сделаной программистами. Я уже не говорю про простенькую типографику,- я этих «док», «вик», «спек» насмотрелся раз в 100 больше чем этот «j2ee индус с 8 годами» непонятно где.
в)не согласована. Вот бывает такое есть два документа от двух отделов на одно и то же почти. Один на вики, второй авторизованый pdf. В двух источниках — взаимоисключающая информация. Кому верить?
Какой выход? Думать всегда головой своей. Разбираться в проекте глубоко, ТЩАТЕЛЬНО взвешивать любую входную информацию, АНАЛИЗИРОВАТЬ ее. Потому что люди, которые полагаются на документацию — только потому что «я забрал ее из cvs/svn а дальше меня ничего не интересует», прикрывают сугубо свою собственную задницу(это мое имхо), и по моему опыту работу, им глубоко начхать на проект, для них главное — не взять на себя ответственность.
9. Никогда не доверяйте документации и тем более не полагайтесь на нее. Этому правилу меня научил мой зав. кафедры xx лет назад. За мою xx летнюю карьеру это правило работало всегда и везде от мелких проектов до крупных, причем даже там, где казалось бы всё должно быть совершенно «по плану». Нифига.
Кроме того я бы изменил 10 пункт, просто потому что он совершенно не работает. Нет, не смотреть чужой код совсем — нельзя, но сформулировать можно и так:
10. Чужой код может ПЛОХОМУ научить. Самое худшее что может к вам привязаться, это чужая плохая привычка. Что я имею ввиду, любой проект всегда имеет какие-то рамки, вы не знаете, что конкретно сподвигло человека писать это и именно это. Обычно люди не пишут в комментариях — «тут ко мне подошел шеф и заставил сократил срок сдачи до завтрашнего утра, поэтому, ув. читатель моего кода, с этого момента качество моего кода немного упадет, так что учтите этот фактор при дальнейшем прочтении». Такое не пишут. По моему опыту, чем опытнее программист, тем больше он ИСПРАВЛЯЕТ в чужом коде, чем его ЧИТАЕТ. Поэтому такое правило, ну вы знаете, на ваш страх и риск.
И последнее. 7 пункт, я бы тоже изменил примерно вот так:
7. Не пугайтесь, но и в тоже время ИЗБЕГАЙТЕ быстрой смены технологий. Потому что с годами понимаешь, это ни к чему не приводит.
В целом с иными пунктами я целиком и полностью согласен с автором.
Где нынче minix — ты спрашиваешь? А я спрошу лучше, а где нынче Linux нет и почему там Linux нет, может быть тогда какой-то конструктив появится от тебя.