Мне кажется, что больше нужно напирать не на технологии, а на интерфейсы. Интерфейсы стандартизируются, а технологии далеко не всегда. Поэтому нужно ставить вопрос не о том, сколько нужно изучать конкретную технологию, а взглянуть на интерфейсы, которые она поддерживает, чтобы понять, пригодится ли технология в принципе и какую часть от технологии стоит изучать. Технологии бывают очень заумные и не всегда все части технологии нужны. Очень хорошо, если технология поддаётся разделению на части, потому что конечный продукт это далеко не одна технология, а их сумма. Просто нужно стараться не сильно увеличивать сумму неиспользуемых частей в проекте.
Мой вывод такой — интерфейсы нужно учить всегда и в это нужно вкладываться и не жалеть времени, а технологии просто берутся и тратиться нужно в основном на изучение части, которая подходит к нужному интерфейсу.
P.S.
Технологии, конечно, нужно учить, но с оглядкой на то, как быстро она начнёт приносит профит в какой-то части разработки.Особенно интересно «проникаться» технологией, когда читаешь документацию и вдруг ловишь себя на мысли — «Вау, КРУТО! Я бы до этого не догадался» или «Да, я тоже так бы сделал». ))) Тогда и освоение идёт быстрее.
Вот мои правила.
1. Исходный код пишется не для компьютера, а для людей.
2. Документировать/кормментировать код, писать документацию для разработчика (как запустить программу на отладку, где смотреть логи и т.д.), делать скриншоты. (со скриншотами всегда заморочка, а где их хранить? Я предпочитаю выложить изображение скриншота на фотохостинг, а в код кинуть ссылку на скриншот).
3. Если я использую код, найденный в интернете, то даю ссылку перед этим кодом, что код взят оттуда-то, чтобы читающий мог перейти и глянуть в каком контексте это было использовано там, да и описание почитать будет не лишним. 4. Радуюсь, что оставил комментарий, ссылку или скриншот к запутанному месту в своём коде через полгода.
undefined — это работа на клиенте, тут всё просто и по идее до клиента такие ошибки доходить не должны.
Просто если сосредоточиться на обработке ошибок ajax, то с сервера в ответ на ajax запрос может прийти ответ, к которому клиент совсем не будет готов и при этом это не будет ошибкой сервера! Ошибку может сгенерировать фильтр сервера, когда до вашего приложения дело ещё не дошло и формат ошибки тоже может быть неожиданным для клиента. Вот вы ожидаете text, а приходит xml или json, а может csv!? Но это тоже не гарантия, что сервер вернул вам что-то из разряда того, что вы ожидаете и что именно ваше приложение сформировало сообщение об ошибке.
За те года, что существует ajax я не видел универсального решения этой проблемы. Ведь проблема формулируется просто — надо как-то дать понять, что именно моя программа обработала запрос. Даже если вы возвращаете ошибку 500 это не гарантирует клиенту, что именно ваша серверная часть вернула эту ошибку. По сути 500 ошибку, которую сгенерировала ваша программа не отличить от такой же ошибки, сгенерированной самим сервером. Процентах в 90 случаев это может выручить, но никогда нельзя быть уверенным, что если в вашем проекте на тесте надежда что 90% уверенности работали в 100% случаев, то в продакшене не случиться, что эти 90% уверенности работают только в 50% случаев, а то и меньше.
Простите за занудство. Меня эта проблема бесит. :)
Если API разрабатываются отдельно, то ошибка обрабатывается по HTTP коду или кастомному строчному коду, это лучше делать сразу в методе сервиса который делает AJAX запрос.
Остальные ошибки чаще всего вообще никак не обрабатываются, предполагается что их быть не должно, а если все-таки случились, пользователь догадается перегрузить страницу."
Нет ли всё-таки другого варианта сообщить о «странном» ответе от сервера? Насколько я могу судить — это очень болезненная тема в разработке с ajax-запросами. Ведь ошибки бывают в бизнеслогике и её уже никак не свалить на код 500. В этом случае сервер будет пытаться честно предупредить клиента. Что же делать клиенту? Вдруг у него форма на 20-30 полей и перезагрузка страницы ооочень расстроит его. Простите, что несколько придираюсь и утрирую, но не может быть, чтобы не было решения?
А я-то не догадался, что его заказать можно. Всё в канцелярских магазинах спрашивал, но там такого нет.
Вот такое устройство было бы отличным подспорьем:
Хороший пост. От себя добавлю, что иногда обхожу некоторых участников предстоящего совещания за день-два и озвучиваю свои вопросы или предложения (по моей части), чтобы до совещания все переварили или задали вопросы в неформальной обстановке. Поэтому мои вопросы или предложения уже на совещании как правило проходят достаточно гладко и обычно собирают быстрое согласие участников.
Задача утилиты — просто небольшой сервис без претензий. Посмотреть на состояние нескольких репозиториев (не обязательно это код, у меня есть парочка «блокнотов», куда я веду свои записи со скриншотами; я к ним настолько привык и так давно веду, что иногда забываю их коммитить). Потом у меня есть парочка файлов, которые обновляются автоматически — скрипты fiddler2 и его Composer-Scratchpad. Они тоже сохраняются автоматически. И все эти вещи раскиданы по дискам. Пусть их и 5-10 штук, но требуют постоянных одинаковых нажатий мышкой. А так сейчас это программа за меня сделает быстрее.
Попробуйте делать небольшие коммиты почаще
Я достаточно часто делаю коммиты, а ещё пишу сопроводительную документацию для разработчиков. Помогает даже мне, когда через полгода возвращаюсь к проекту и тогда каждая запятая на вес золота, а каждый лишний скриншот — клад.
Опять же, Ваша утилита даже имя текущей ветки не показывает.
Ваше замечание очень уместно! Теперь есть текущая ветка и в tooltip показывает последнее сообщение, с которым был произведён commit:
Но мне кажется, если начнете углубляться, то окажется, что копируете GUI вроде того же Tortoise
Честно говоря у меня было тайное желание прикрутить к каждому пункту все контекстные меню Tortoise, просто, чтобы не переходить в подкаталоги и не делать лишних щелчков мыши. Если бы можно было бы вызывать функцию формирования контекстного меню как это делает Windows, передавая в dll TortoiseGit ссылку на своё контекстное меню, да на C#, то круто… Но боюсь, что это невозможно.
А так — самые ежедневные клики.
Поскольку каждая библиотека пишется под свою среду, то иногда всё-таки очень удобно заграбастать что-то, написанное на javascript, php, python и других языках https://en.wikipedia.org/wiki/List_of_JVM_languages. По мне так это просто здорово, что я могу взять что-то на javascript и использовать в java. Единственную проблему, которую я вижу — отладка такого кода. Но для JavaScript эта проблема решена в Idea: https://blog.jetbrains.com/idea/2014/03/debugger-for-jdk8s-nashorn-javascript-in-intellij-idea-13-1/ а вот для Eclipse всё никак не сделают. Есть ли отладчики для других языков пока не слышал, но направление хорошее.
И от программирования может тошнить, даже если это любимое занятие. В этом случае я очень переживаю, что не научился играть ни на одном музыкальном инструменте. Иногда взял бы электрогитару и запилил бы соло через усилок, например, High Way Star или отбарабанить как Мэл Тейлор. Или какой-нибудь фильмец посмотреть на английском без перевода с оригинальной озвучкой, которая при переводе сильно страдает (как простой пример, естественно).
Если говорить об обучении, то ребёнку нужно просто показать, насколько жизнь может быть интереснее, когда он может самостоятельно добиться своей цели. И как раз всё вместе — музыка, иностранные языки, программирование и куча других способностей именно этому и способствуют.
Обрусевший иностранец. Кстати, может быть немного напутал — скорее всего отчества нет. Его все по имени зовут, даже как-то неловко, хоть он выглядит далеко не как пацан.
У меня заказчик внутренней программы, имеющий список пользователей, был без фамилии. И это ЕДИНСТВЕННЫЙ человек во всей организации, у которого её не было!
В итоге я решил отказаться от баллона. В C# на него почти ничего не повесить. Поэтому перешёл на WPF-popup и вот пример:
Единственно, чего нет — хвостика, указывающего на иконку. А так теперь можно что угодно добавить. Хоть превьюшку, если файл является картинкой. (По таймеру, чтобы не подвешивать систему на каждом файле).
Хотел бы узнать ваше мнение.
Для определения имени пользователя, удалившего файл, требуется регистрация события безопасности в журнале windows security, поэтому требуется дополнительная настройка windows (в групповой политике включить ведение журнала). Так оказывается консоли групповой политики нет в Windows Home, хотя сама политика есть. В принципе можно написать функцию, которая выставит эту политику. Но не будет ли такая функция «пугать» пользователей (естественно она будет спрашивать разрешения)?
P.S.
Если бы можно было узнать координаты иконки, то и хвостик можно было бы нарисовать. XAML творит чудеса.
Я бы предложил первым пунктом в документации указать какая у программы самая главная функция, ради чего она писалась и почему пользователь должен выбрать вашу программу именно за «это», этакий вау-эффект, а инструкция по установке уже вторым пунктом. Это надо писать не только на сайте самой программы (если таковой вообще есть), а по возможности в нескольких местах. Я так не один проект открыл и закрыл (не зацепило или сходу не разобрался, в то время как соседи по выборке предлагали более внятное объяснение).
Для примера, на сайте microsoft ооочень много плохой документации. Дофига описания как установить, но нет никакой возможности понять, а что я получу в результате настройки или установки? Не стоит надеяться на «опыт» пользователя, что он всё правильно себе представит.
Если программа зацепила, то какая бы «странная» не была установка — есть мотивация её осилить.
Мой вывод такой — интерфейсы нужно учить всегда и в это нужно вкладываться и не жалеть времени, а технологии просто берутся и тратиться нужно в основном на изучение части, которая подходит к нужному интерфейсу.
P.S.
Технологии, конечно, нужно учить, но с оглядкой на то, как быстро она начнёт приносит профит в какой-то части разработки.Особенно интересно «проникаться» технологией, когда читаешь документацию и вдруг ловишь себя на мысли — «Вау, КРУТО! Я бы до этого не догадался» или «Да, я тоже так бы сделал». ))) Тогда и освоение идёт быстрее.
1. Исходный код пишется не для компьютера, а для людей.
2. Документировать/кормментировать код, писать документацию для разработчика (как запустить программу на отладку, где смотреть логи и т.д.), делать скриншоты. (со скриншотами всегда заморочка, а где их хранить? Я предпочитаю выложить изображение скриншота на фотохостинг, а в код кинуть ссылку на скриншот).
3. Если я использую код, найденный в интернете, то даю ссылку перед этим кодом, что код взят оттуда-то, чтобы читающий мог перейти и глянуть в каком контексте это было использовано там, да и описание почитать будет не лишним.
4. Радуюсь, что оставил комментарий, ссылку или скриншот к запутанному месту в своём коде через полгода.
Просто если сосредоточиться на обработке ошибок ajax, то с сервера в ответ на ajax запрос может прийти ответ, к которому клиент совсем не будет готов и при этом это не будет ошибкой сервера! Ошибку может сгенерировать фильтр сервера, когда до вашего приложения дело ещё не дошло и формат ошибки тоже может быть неожиданным для клиента. Вот вы ожидаете text, а приходит xml или json, а может csv!? Но это тоже не гарантия, что сервер вернул вам что-то из разряда того, что вы ожидаете и что именно ваше приложение сформировало сообщение об ошибке.
За те года, что существует ajax я не видел универсального решения этой проблемы. Ведь проблема формулируется просто — надо как-то дать понять, что именно моя программа обработала запрос. Даже если вы возвращаете ошибку 500 это не гарантирует клиенту, что именно ваша серверная часть вернула эту ошибку. По сути 500 ошибку, которую сгенерировала ваша программа не отличить от такой же ошибки, сгенерированной самим сервером. Процентах в 90 случаев это может выручить, но никогда нельзя быть уверенным, что если в вашем проекте на тесте надежда что 90% уверенности работали в 100% случаев, то в продакшене не случиться, что эти 90% уверенности работают только в 50% случаев, а то и меньше.
Простите за занудство. Меня эта проблема бесит. :)
Нет ли всё-таки другого варианта сообщить о «странном» ответе от сервера? Насколько я могу судить — это очень болезненная тема в разработке с ajax-запросами. Ведь ошибки бывают в бизнеслогике и её уже никак не свалить на код 500. В этом случае сервер будет пытаться честно предупредить клиента. Что же делать клиенту? Вдруг у него форма на 20-30 полей и перезагрузка страницы ооочень расстроит его. Простите, что несколько придираюсь и утрирую, но не может быть, чтобы не было решения?
Вот такое устройство было бы отличным подспорьем:
Задача утилиты — просто небольшой сервис без претензий. Посмотреть на состояние нескольких репозиториев (не обязательно это код, у меня есть парочка «блокнотов», куда я веду свои записи со скриншотами; я к ним настолько привык и так давно веду, что иногда забываю их коммитить). Потом у меня есть парочка файлов, которые обновляются автоматически — скрипты fiddler2 и его Composer-Scratchpad. Они тоже сохраняются автоматически. И все эти вещи раскиданы по дискам. Пусть их и 5-10 штук, но требуют постоянных одинаковых нажатий мышкой. А так сейчас это программа за меня сделает быстрее.
Я достаточно часто делаю коммиты, а ещё пишу сопроводительную документацию для разработчиков. Помогает даже мне, когда через полгода возвращаюсь к проекту и тогда каждая запятая на вес золота, а каждый лишний скриншот — клад.
Ваше замечание очень уместно! Теперь есть текущая ветка и в tooltip показывает последнее сообщение, с которым был произведён commit:
https://github.com/satabol/git_repositories_scanner/releases/tag/v0.0.90
Такой вариант удобнее?
Честно говоря у меня было тайное желание прикрутить к каждому пункту все контекстные меню Tortoise, просто, чтобы не переходить в подкаталоги и не делать лишних щелчков мыши. Если бы можно было бы вызывать функцию формирования контекстного меню как это делает Windows, передавая в dll TortoiseGit ссылку на своё контекстное меню, да на C#, то круто… Но боюсь, что это невозможно.
А так — самые ежедневные клики.
Если говорить об обучении, то ребёнку нужно просто показать, насколько жизнь может быть интереснее, когда он может самостоятельно добиться своей цели. И как раз всё вместе — музыка, иностранные языки, программирование и куча других способностей именно этому и способствуют.
Единственно, чего нет — хвостика, указывающего на иконку. А так теперь можно что угодно добавить. Хоть превьюшку, если файл является картинкой. (По таймеру, чтобы не подвешивать систему на каждом файле).
Хотел бы узнать ваше мнение.
Для определения имени пользователя, удалившего файл, требуется регистрация события безопасности в журнале windows security, поэтому требуется дополнительная настройка windows (в групповой политике включить ведение журнала). Так оказывается консоли групповой политики нет в Windows Home, хотя сама политика есть. В принципе можно написать функцию, которая выставит эту политику. Но не будет ли такая функция «пугать» пользователей (естественно она будет спрашивать разрешения)?
P.S.
Если бы можно было узнать координаты иконки, то и хвостик можно было бы нарисовать. XAML творит чудеса.
Запускающая команда будет располагаться справа от имени файла. А слева — как обычно, открытие каталога.
Так удобно будет? (иконки, конечно, поменяю)
Я бы предложил первым пунктом в документации указать какая у программы самая главная функция, ради чего она писалась и почему пользователь должен выбрать вашу программу именно за «это», этакий вау-эффект, а инструкция по установке уже вторым пунктом. Это надо писать не только на сайте самой программы (если таковой вообще есть), а по возможности в нескольких местах. Я так не один проект открыл и закрыл (не зацепило или сходу не разобрался, в то время как соседи по выборке предлагали более внятное объяснение).
Для примера, на сайте microsoft ооочень много плохой документации. Дофига описания как установить, но нет никакой возможности понять, а что я получу в результате настройки или установки? Не стоит надеяться на «опыт» пользователя, что он всё правильно себе представит.
Если программа зацепила, то какая бы «странная» не была установка — есть мотивация её осилить.