Как я догадываюсь, кроме этих будут ведь и элементарные вопросы? Если так, то задания отличные, хотя можно было бы ещё и парочку посложнее добавить. Кстати, я в детстве нашёл книгу по информатике готов 70х, так там задания были сложнее. В том числе и про робота с такой же системой команд.
Но… Ходят слухи, что теперь ВУЗам запретили принимать экзамены по предметам, по которым проводится ЕГЭ. Если это — правда, то задания слишком лёгкие для серьёзного ВУЗа.
> Как показывает практика, когда внедряешь для какого-нибудь функционала работу без перезагрузки страницы, им гораздо чаще начинают пользоваться.
Так это же замечательно! В целом аргумент принят.
> Работа аякса невозможна без использования ТСР-сокетов.
Я не идиот, не надо мне это объяснять. То, что вы написали подробно, я написал кратко — это разные уровни. Я иммел в виду, что в JS вы используете более специализированный AJAX (если и сейчас не понято — доставьте наиболее понравившийся синоним синоним «менее абстрактный», «высокоуровневый»), который обладает ограничениями и недостатками, которых лишён TCP.
> Вы сейчас хотите сказать, что HTTP работает через UDP-сокеты?
Где именно я это хочу сказать?
> Нормальный веб-сервер не пробовали использовать?
Пробовали. TCP быстрее. Есть догадки, что тормоза есть в том числе и на стороне браузера — время ожидания в консоли FireBug-а значительно меньше времени генерации ответа сервером. Сниферить не пробовали. Строго говоря, веб-сервер (lighttpd) работает шустро, тормоза у нас создаёт и FCGI-сервер, для которого веб-сервер является клиентом. Конечно, лишняя прослойка скорости не добавляет, но это — дань модульности и универсальности решения.
> Ну да, HTTP работает по TCP.
Хорошо, давайте по пунктам. Протокол TCP обладает большими стандартными возможностями, чем технология AJAX (подробности и оговорки о js.io, comet и пр. см. выше.). Пусть это будет, например, возможность передачи данных сервером без запроса клиентом — удобно, например, для чата или другой передачи данных между пользователями. Если мне из JS-кода доступен AJAX, но не доступен TCP, я не могу считать, что я могу использовать возможности TCP, так как указанная возможность мне не доступна.
Вы же в рассуждениях, видимо, считаете, что возможность использования технологии и возможность её _ограниченного_ использования — это одно и то же.
> Ой, освежите всё же свои знания. Ну правда. У вас така-а-а-я каша в голове…
Было бы весьма неплохо, если бы вы указали на конкретные пробелы в моих знаниях, а то работать старшим разработчиком в области создания серверных компонент как-то тяжеловато, будучи таким недалёким.
Любой вменяемый и технически грамотный, если ему есть, что терять в случае мошенничества.
Технически неграмотным людям пользоваться серьёзными техническими средствами противопоказано по определению — в любой области, от судоводства до самолётостроения.
Что-то я не понял. А зачем вам понадобилось доверять генерацию секретного ключа сторонней организации?
Это примерно то же самое, что в мастерскую по копированию обычных ключей принести ключ, не оторвав бирку от квартиры с адресом с указанием, где именно деньги лежат. Не фатально, если ключник — честный, но никому не нужно.
>А я вот скажу, что когда AJAX-запросов становится очень много, они существенно снижают число свободных процессов сервера-бекенда
Смотря вкаких случаях. Если, скажем, по клике на элемент грузится только необходимый контент, если JS включен или полностью перезагружается страница, если он выключен (а именно так, как я понимаю, и должно происходить при использовании ненавязчивого JS), то количество запросов для обоих случаях не изменится, но AJAX-запросы для сервера будут легче, ибо остальной контент рендерить серверу не придётся. К тому же перезагрузка страницы вызывает как минимум проверку на обновление некоторых статических данных — скриптов, картинок, стилей.
> Вы явно путаетесь в терминологии
Ничуть, я считаю, что достаточно неплохо владею теорией по сетям. AJAX-запрос — это не TCP-сокет функционально — например, вы не можете, например, в одностороннем порядке передать данные от сервера к клиенту (давайте comet, js.io, выталкивания буфера в постоянно грузящейся веб-странице и прочие плохо работающие вещи, мы учитывать не будем). TCP и AJAX — это разные уровни сетевых технологий, причём более высокоуровневая из них предоставляет меньшие возможности. В частности, не будем забывать, что в AJAX запросы архитектурно асинхронные, это означает возможное несовпадение порядка запросов и ответов от сервера, что не всегда приемлимо. В частости, по упомянутой мною ссылке есть такая проблема — если быстро тыкать мышой на пункты меню, может возникнуть ситуация, когда ответ на непоследний запрос будет последним и браузер покажет пользователю не то, что он хотел. Запрещать повторную отсылку запроса только потому, что не пришёл ответ на ещё один на ту же группу данных не есть хорошо. Я не говорю, что проблема нерешаемая — но в TCP такого нет.
Есть более серьёзный проект, в котором зажержки из-за периодического открытия TCP-соединений (сразу скажу — про существование перманентного соединения в HTTP/1.1 я тоже знаю) для AJAX-запросов — это плохо. Поскольку почти во всех браузерах существует способ в некоторых случаях открыть TCP-соединение, мы предпочитаем использовать его, и только в противном случае подключаем AJAX.
У меня наоборот — 6 строчек сделали AJAX-функциональность, доступную и без JS, что и было целью после того, как были поняты ограничения JS.
В целом AJAX даёт меньшую нагрузку на сервер, чем генерация полноценных страниц хотя бы за счёт отсутствия необходимости применения шаблонизатора и подсчётом всех параметров шаблона. Кое-где в одном из проектов, где я учавствую, мы используем даже передачу данных через TCP-сокет в веб-страницах нашего приложения вместо AJAX-запросов, чтобы сэкономить на производительности сервера и уменьшить время реакции.
Но в целом, пожалуй, вы мои аргументы по поводу спора о правильности/неправильности использования навязчивого JS не приняли, но поняли, как и я — ваши.
И берёт на себя тяжесть общения с невменяемым заказчиком?
И берёт на себя все риски?
И платит деньги вовремя и быстро, независимо от графика рассчёта заказчика?
И берёт на себя или перераспределяет задачи, которые я не могу выполнить в силу недостаточной квалификации?
В итоге — я знаю python, django и умею создавать сложные серверные приложения, я не хочу заниматься вёрсткой, дизайном, удоством интерфейса, контентом, переводом и прочими вещами, которые мне неинтересны. Строю архитектуру, пишу код, и на полученные деньги рассчитываюсь с кредитом за купленную квартиру. Сплю я спокойно, ведь все описанные выше проблемы — решает шеф.
Итак, в каких ситуациях помогает (или даже спасает) использование VCS:
1. Сохранение истории кода — в любой момент времени мы можем вернуться к любому зафиксированному состоянию проекта. Машина времени — это не миф!
2. Синхронизация кода — при участии в проекте более одного человека система позволяет безболезненно производить слияние разных версий исходных текстов.
3. Сохранность кода — при использовании VCS исходный код лежит на рабочих машинах всех разработчиков + на сервере. В такой ситуации потерять код довольно сложно.
— От себя:
4. Если ломается функционал, который ранее работал, меня интересует, когда и почему он сломался. Я пишу тест на этот случай и перебором тестирую все версии от последней до момента, когда тест пройден. А вас интересует, откуда появляются баги в старом функционале? Как решаете?
5. Комментарии в CSV хорошо подходят вместо отчёта.
Если SVN — тормоза, ну попробуйте тогда git или mercurial, что ли.
В команде последнего проекта, где я участвовал (человек 12) всех предупреждали о необходимости писать ежедневные отчёты, и не раз. Не помогало. На репрессии люди естественным образом обижаются и уходят, а отчёты писать тогда мало кто начал.
Про себя: Поначалу я писал. На понятную менеджеру формулировку тратится дофига времени и сил. При том, что менеджер хороший и в технических знаниях даст мне фору много раз подряд, просто естественным образом не в теме всех деталей моих задач, которые знаю я. Я не стал игнорировать отчёты, просто объяснил по-человечески, что мне тяжело тратить кучу времени на вербальную формулировку своих действий — ведь порой исправить баг быстрее, чем описать его комментарием коммита. Так в коммите понимающему человеку виден контекст, где были произведены изменения, что в отчёте пришлось бы описывать отдельно. К тому же между задачами часто переключаешься, отвлекаешься на сопутствующие проблемы и проблемы других разработчиков, в итоге тяжело понять, сколько именно на что потратил.
У меня отчёт сейчас: количество потраченного времени всего и на какой род деятельности я его потратил в основном — правка багов, совместная работа, чтение документации или работа по тикетам.
Подгонка раздутием количества часов не интересна по причине отсутствия строгого контроля за их суммарным количеством. Хотя на самом деле следствие, видимо, обратное.
Выполнение задач с отчётом по часам мне не интересно по причине резкого падения качества моего кода в этом случае — если я напишу как получится там, где нужно взвешенное архитектурное решение или в силу гонки за часы откажусь от назревшего рефакторинга, требующего нескольких дней работы, в перспективе результат будет только хуже.
Если шефа интересуют подробности того, что я делаю или делал сегодня и он не может понять это по логам VCS и статусу тикетов — он спрашивает, в этот же день.
Итого:
Ежедневные отчёты с расписанием задач — страшное зло.
Менеджер обязан уметь читать логи VCS и статусы изменения тикетов.
Исследование деталей работ можно производить при подозрении на неудовлетворительную производительность или из технического любопытства, но не ежедневно.
Руководство — не контора, а в таких масштабах — так вообще мало что общего у них. Я уже не намекаю даже — руководство не получит прибыли от оплаты дорогостоящего, хорошего доступа в сеть. А контора — получит выгоду.
Да, с HTML выразился неточно. Имел в виду, что веб-сайт — это набор страниц на (X)HTML, а веб-браузер — программа, отображающая (X)HTML. Более никаких обязательств в браузер не закладывается. А мы говорим именно о веб-сайтах и веб-браузерах.
Подведу итог ещё раз: вы не рекомендуете мне пользоваться сайтами, использующими местами глючную, местами — вообще не работающую популярную современную технологию, которая, собственно, работать даже и не должна в силу отсутствия стандарта.
P.S. Под отсутствием стандарта я понимаю не JS в отдельности, а его связку с HTML.
Ваша мысль мне ясна. Хотя в оригинале говорилось о 90% функционала 10% средствами, а не о том, что 10% пользователей не смогут в принципе воспользоваться ресурсом. Впрочем, есть отличная цитата и на ваш случай:
«Лучше получить удовлетворительное решение, но в срок, чем полное к тому времени, когда оно станет бесполезным».
По поводу цифр о 90% времени — я уже привёл их для себя. Включил голову и дописал 6 строчек кода. Что я делаю неправильно?
Я правильно понял, что вы считаете, что делать JavaScript ненавязчивым профессионалам(!) даётся с трудом?
> Там, где интернет нужен — есть технические средства в актуальном, для потребления интернета, состоянии.
Вообще-то совсем даже нет, скорее наоборот. Но в моём случае такие технические средства имеются. И у меня есть техническая возможность заплатить за это деньги, чтобы я мог использовать быстрый интернет по работе.
> Какие факты я искажаю?
Что конторе не нужен современный интернет. Это не так. Во внутреннем форуме тема о попытках изменить ситуацию создаётся ежегодно.
>… и как факт может возникнуть мифическая ситуация…
То, что вы пишите — мифическая, моя ситация — конкретная, я её уже разжевал как мог.
>… веб-разработчики должны делать свои сайты с учётом этого…
Я не хочу, чтобы разработчики заморачивались по поводу каждого браузера, не поддерживающего или криво поддерживающего стандарты. Разработчики должны делать сайты в соответствии со стандартами. Стандарт HTML не подразумевает наличие JS в браузере. Готов признать, что картинки-капчи хоть и делают работу в текстовом браузере неудобной, всё же не делают её невозможной совсем, потому что:
1. Я имею возможность сохранить картинку-капчу по урлу и посмотреть её на ме-е-д-д-ленном канале, если графика у меня пашет. Собственно, так я и делаю.
2. Для вопросов поднятия графики/сервера с консоли используются грамотные информационные ресурсы, сделанные грамотными людьми, где картинки-капчи если и используются, то для получения информации не обязательны.
Но… Ходят слухи, что теперь ВУЗам запретили принимать экзамены по предметам, по которым проводится ЕГЭ. Если это — правда, то задания слишком лёгкие для серьёзного ВУЗа.
Так это же замечательно! В целом аргумент принят.
> Работа аякса невозможна без использования ТСР-сокетов.
Я не идиот, не надо мне это объяснять. То, что вы написали подробно, я написал кратко — это разные уровни. Я иммел в виду, что в JS вы используете более специализированный AJAX (если и сейчас не понято — доставьте наиболее понравившийся синоним синоним «менее абстрактный», «высокоуровневый»), который обладает ограничениями и недостатками, которых лишён TCP.
> Вы сейчас хотите сказать, что HTTP работает через UDP-сокеты?
Где именно я это хочу сказать?
> Нормальный веб-сервер не пробовали использовать?
Пробовали. TCP быстрее. Есть догадки, что тормоза есть в том числе и на стороне браузера — время ожидания в консоли FireBug-а значительно меньше времени генерации ответа сервером. Сниферить не пробовали. Строго говоря, веб-сервер (lighttpd) работает шустро, тормоза у нас создаёт и FCGI-сервер, для которого веб-сервер является клиентом. Конечно, лишняя прослойка скорости не добавляет, но это — дань модульности и универсальности решения.
> Ну да, HTTP работает по TCP.
Хорошо, давайте по пунктам. Протокол TCP обладает большими стандартными возможностями, чем технология AJAX (подробности и оговорки о js.io, comet и пр. см. выше.). Пусть это будет, например, возможность передачи данных сервером без запроса клиентом — удобно, например, для чата или другой передачи данных между пользователями. Если мне из JS-кода доступен AJAX, но не доступен TCP, я не могу считать, что я могу использовать возможности TCP, так как указанная возможность мне не доступна.
Вы же в рассуждениях, видимо, считаете, что возможность использования технологии и возможность её _ограниченного_ использования — это одно и то же.
> Ой, освежите всё же свои знания. Ну правда. У вас така-а-а-я каша в голове…
Было бы весьма неплохо, если бы вы указали на конкретные пробелы в моих знаниях, а то работать старшим разработчиком в области создания серверных компонент как-то тяжеловато, будучи таким недалёким.
Мысль: а ещё иногда google docs можно использовать для совместного редактирования на ходу.
Технически неграмотным людям пользоваться серьёзными техническими средствами противопоказано по определению — в любой области, от судоводства до самолётостроения.
Это примерно то же самое, что в мастерскую по копированию обычных ключей принести ключ, не оторвав бирку от квартиры с адресом с указанием, где именно деньги лежат. Не фатально, если ключник — честный, но никому не нужно.
Смотря вкаких случаях. Если, скажем, по клике на элемент грузится только необходимый контент, если JS включен или полностью перезагружается страница, если он выключен (а именно так, как я понимаю, и должно происходить при использовании ненавязчивого JS), то количество запросов для обоих случаях не изменится, но AJAX-запросы для сервера будут легче, ибо остальной контент рендерить серверу не придётся. К тому же перезагрузка страницы вызывает как минимум проверку на обновление некоторых статических данных — скриптов, картинок, стилей.
> Вы явно путаетесь в терминологии
Ничуть, я считаю, что достаточно неплохо владею теорией по сетям. AJAX-запрос — это не TCP-сокет функционально — например, вы не можете, например, в одностороннем порядке передать данные от сервера к клиенту (давайте comet, js.io, выталкивания буфера в постоянно грузящейся веб-странице и прочие плохо работающие вещи, мы учитывать не будем). TCP и AJAX — это разные уровни сетевых технологий, причём более высокоуровневая из них предоставляет меньшие возможности. В частности, не будем забывать, что в AJAX запросы архитектурно асинхронные, это означает возможное несовпадение порядка запросов и ответов от сервера, что не всегда приемлимо. В частости, по упомянутой мною ссылке есть такая проблема — если быстро тыкать мышой на пункты меню, может возникнуть ситуация, когда ответ на непоследний запрос будет последним и браузер покажет пользователю не то, что он хотел. Запрещать повторную отсылку запроса только потому, что не пришёл ответ на ещё один на ту же группу данных не есть хорошо. Я не говорю, что проблема нерешаемая — но в TCP такого нет.
Есть более серьёзный проект, в котором зажержки из-за периодического открытия TCP-соединений (сразу скажу — про существование перманентного соединения в HTTP/1.1 я тоже знаю) для AJAX-запросов — это плохо. Поскольку почти во всех браузерах существует способ в некоторых случаях открыть TCP-соединение, мы предпочитаем использовать его, и только в противном случае подключаем AJAX.
В целом AJAX даёт меньшую нагрузку на сервер, чем генерация полноценных страниц хотя бы за счёт отсутствия необходимости применения шаблонизатора и подсчётом всех параметров шаблона. Кое-где в одном из проектов, где я учавствую, мы используем даже передачу данных через TCP-сокет в веб-страницах нашего приложения вместо AJAX-запросов, чтобы сэкономить на производительности сервера и уменьшить время реакции.
Но в целом, пожалуй, вы мои аргументы по поводу спора о правильности/неправильности использования навязчивого JS не приняли, но поняли, как и я — ваши.
И берёт на себя все риски?
И платит деньги вовремя и быстро, независимо от графика рассчёта заказчика?
И берёт на себя или перераспределяет задачи, которые я не могу выполнить в силу недостаточной квалификации?
В итоге — я знаю python, django и умею создавать сложные серверные приложения, я не хочу заниматься вёрсткой, дизайном, удоством интерфейса, контентом, переводом и прочими вещами, которые мне неинтересны. Строю архитектуру, пишу код, и на полученные деньги рассчитываюсь с кредитом за купленную квартиру. Сплю я спокойно, ведь все описанные выше проблемы — решает шеф.
Почему бы не взглянуть на это с такой сторны?
Итак, в каких ситуациях помогает (или даже спасает) использование VCS:
1. Сохранение истории кода — в любой момент времени мы можем вернуться к любому зафиксированному состоянию проекта. Машина времени — это не миф!
2. Синхронизация кода — при участии в проекте более одного человека система позволяет безболезненно производить слияние разных версий исходных текстов.
3. Сохранность кода — при использовании VCS исходный код лежит на рабочих машинах всех разработчиков + на сервере. В такой ситуации потерять код довольно сложно.
— От себя:
4. Если ломается функционал, который ранее работал, меня интересует, когда и почему он сломался. Я пишу тест на этот случай и перебором тестирую все версии от последней до момента, когда тест пройден. А вас интересует, откуда появляются баги в старом функционале? Как решаете?
5. Комментарии в CSV хорошо подходят вместо отчёта.
Если SVN — тормоза, ну попробуйте тогда git или mercurial, что ли.
Про себя: Поначалу я писал. На понятную менеджеру формулировку тратится дофига времени и сил. При том, что менеджер хороший и в технических знаниях даст мне фору много раз подряд, просто естественным образом не в теме всех деталей моих задач, которые знаю я. Я не стал игнорировать отчёты, просто объяснил по-человечески, что мне тяжело тратить кучу времени на вербальную формулировку своих действий — ведь порой исправить баг быстрее, чем описать его комментарием коммита. Так в коммите понимающему человеку виден контекст, где были произведены изменения, что в отчёте пришлось бы описывать отдельно. К тому же между задачами часто переключаешься, отвлекаешься на сопутствующие проблемы и проблемы других разработчиков, в итоге тяжело понять, сколько именно на что потратил.
У меня отчёт сейчас: количество потраченного времени всего и на какой род деятельности я его потратил в основном — правка багов, совместная работа, чтение документации или работа по тикетам.
Подгонка раздутием количества часов не интересна по причине отсутствия строгого контроля за их суммарным количеством. Хотя на самом деле следствие, видимо, обратное.
Выполнение задач с отчётом по часам мне не интересно по причине резкого падения качества моего кода в этом случае — если я напишу как получится там, где нужно взвешенное архитектурное решение или в силу гонки за часы откажусь от назревшего рефакторинга, требующего нескольких дней работы, в перспективе результат будет только хуже.
Если шефа интересуют подробности того, что я делаю или делал сегодня и он не может понять это по логам VCS и статусу тикетов — он спрашивает, в этот же день.
Итого:
Ежедневные отчёты с расписанием задач — страшное зло.
Менеджер обязан уметь читать логи VCS и статусы изменения тикетов.
Исследование деталей работ можно производить при подозрении на неудовлетворительную производительность или из технического любопытства, но не ежедневно.
Да, с HTML выразился неточно. Имел в виду, что веб-сайт — это набор страниц на (X)HTML, а веб-браузер — программа, отображающая (X)HTML. Более никаких обязательств в браузер не закладывается. А мы говорим именно о веб-сайтах и веб-браузерах.
Подведу итог ещё раз: вы не рекомендуете мне пользоваться сайтами, использующими местами глючную, местами — вообще не работающую популярную современную технологию, которая, собственно, работать даже и не должна в силу отсутствия стандарта.
P.S. Под отсутствием стандарта я понимаю не JS в отдельности, а его связку с HTML.
«Лучше получить удовлетворительное решение, но в срок, чем полное к тому времени, когда оно станет бесполезным».
По поводу цифр о 90% времени — я уже привёл их для себя. Включил голову и дописал 6 строчек кода. Что я делаю неправильно?
Я правильно понял, что вы считаете, что делать JavaScript ненавязчивым профессионалам(!) даётся с трудом?
Вообще-то совсем даже нет, скорее наоборот. Но в моём случае такие технические средства имеются. И у меня есть техническая возможность заплатить за это деньги, чтобы я мог использовать быстрый интернет по работе.
> Какие факты я искажаю?
Что конторе не нужен современный интернет. Это не так. Во внутреннем форуме тема о попытках изменить ситуацию создаётся ежегодно.
>… и как факт может возникнуть мифическая ситуация…
То, что вы пишите — мифическая, моя ситация — конкретная, я её уже разжевал как мог.
>… веб-разработчики должны делать свои сайты с учётом этого…
Я не хочу, чтобы разработчики заморачивались по поводу каждого браузера, не поддерживающего или криво поддерживающего стандарты. Разработчики должны делать сайты в соответствии со стандартами. Стандарт HTML не подразумевает наличие JS в браузере. Готов признать, что картинки-капчи хоть и делают работу в текстовом браузере неудобной, всё же не делают её невозможной совсем, потому что:
1. Я имею возможность сохранить картинку-капчу по урлу и посмотреть её на ме-е-д-д-ленном канале, если графика у меня пашет. Собственно, так я и делаю.
2. Для вопросов поднятия графики/сервера с консоли используются грамотные информационные ресурсы, сделанные грамотными людьми, где картинки-капчи если и используются, то для получения информации не обязательны.
Подведу итог: Я против навязчивого JavaScript.