Создание простого веб-приложения, использующего базу ...

All About JavaScript Frameworks

Javascript became a very popular programming language on the past years. In this subreddit we discuss its standards, frameworks and tools
[link]

Java Class : Learning Java the right way

Please direct your questions to /javahelp
[link]

Java News/Tech/Discussion/etc. No programming help, no learning Java

News, Technical discussions, research papers and assorted things of interest related to the Java programming language NO programming help, NO learning Java related questions, NO installing Java questions, NO JVM languages!
[link]

Вкатывание в программирование в зрелом возрасте.

В продолжение https://www.reddit.com/Pikabu/comments/bfm5pz/на_волне_про_работу/?utm_source=share&utm_medium=web2x
Краткая предыстория.

Все началось с того, что я сидел на телефоне технической поддержки уже пару лет на одом месте и перспектив на улучшение не было от слова совсем. Хотелось заниматься более полезным, а не просиживать штаны, да и доход увеличить хотелось. Открыл ХХ.ру с большими ожиданиями (не ну а чо, я ж 5 лет в ИТ, винду могу переставить , 1С поставить - плевое дело), задал в фильтре хорошие условия, которые мне хотелось бы видеть и.... охуел.

Мало того, что требования в сфере ИТ выросли за пару лет до поднебесного состояния, так еще и половина терминов вообще не понятны, не говоря о том, что мое резюме только и подходит, что сидеть на телефоне тех поддержки маленькой конторки.

Окей, курс направления ясен, нужно развиваться, прокачивать скилл, понимать что есть что и уметь это использовать. Дальше гугление, поиски того что оптимально на начальном уровне, еще раз гугление, потом гугление, учеба, гугление, учеба, гугление и вот я работаю программером :)

То что выделил жирным про гугление, это я вам и хочу рассказать. По сути, это тот путь и использование тех инструментов для добычи знаний, который я использовал с большими ошибками, в неправильной очередности. У меня не было человека, который может меня направить, подсказать, рассказать. На работе сказали, что в 25 в программирование уже поздно, а в рашн коммьюнити достаточно сложно из-за завышенного мнения участников, хотя есть и хорошие ребята.

То что будет написано здесь не является стопроцентным правильным подходом, но до тех пор пока не попробуешь, не поймешь. Примерно такое же я советую своим близким людям, кто оказался заложником своей распиздяйской ситуации, как и я. Кто-то отмахивается из-за лени, кто-то яростно поддерживает и дальше не идет, а кто-то молча делает с надеждой на завтра.

План вкатывания и некий роуд-мап на примере языка Python.
  1. Для начала нужно определиться с тем, что вы хотите делать и какой язык учить. Из базовых вещей я могу выделить три основных фундаментальных составляющих для начального уровня: мобильная разработка, веб разработка, бэк. В текущих реалиях фронт-энд (то что вы видите, страница сайта, облик мобильного приложения или просто программы) стал намного сложнее, чем бэк (та часть, где выполняется логика программы, сайта, приложения). Очень много условностей и подходов. На эту тему есть крутой пост на хабр про то, как люди учат JavaScript - https://habr.com/ru/post/312022/ . И это 2016, сейчас наверное вообще жесть что там происходит :) Во фронт меня никогда не тянуло, поэтому я остановился на бэке, не задумываясь. Дальше делал акцент на популярности языка, его синтаксисе, коммьюнити, доступных ресурсах в инете (сайты, форумы, чаты пр.). Остановился я на Python, не жалею ни разу.
  2. Окей, гугл, как выучить питон? Да, гуглить придется оооочень много. Настолько много, что вы наверное сейчас это даже не умеете делать, а про третью страницу в гугле слышали наверное только от знакомых или из мемов. Для того, чтобы начать что-то делать нужен удобный инструмент. В программирование это - IDE или же среда разработки. Программа, в которой вы будете писать код. Тут без вариантов мои авации в сторону PyCharm. Подсветка синтаксиса, подсказки в оформлении, удобный дебаг-режим и прочее, все в одном месте. Версия бесплатная - годная, все что надо есть, скачать тут - https://www.jetbrains.com/pycharm/ . Вообще IDE это больше вкусовщина, кому что больше нравится.
  3. Этот пункт не обязательный, но все же, я считаю, что разработка должна вестись в Linux. Сколько людей, столько и мнений, но меня здесь не переубедить. На момент начала изучения Python у меня был опыт с никсами исключительно самобытный. Установить, посомтреть на красивизну, удивиться скорости и вернуться на windows. Сейчас я уже, наверное, никогда не вернусь к продукту Microsoft, я руками и ногами выступаю за популяризацию Linux и open souce. Для изучения Linux есть хороший курс от команды stepik - https://stepik.org/course/73/promo . Курс бесплатный, по результату сертификат. По выбору ОС, опять же вкусовщина, но я рекомендую либо Linux Mint, либо Ubuntu. Гуглить вопросы по этим дистрибутивам, как и в целом, что основаны на ubuntu достаточно легко.
  4. Где уже python?! Первый курс, что я советую опять же от stepik (вообще крутой ресурс, если что) - https://stepik.org/course/67/syllabus . У курса есть два больших минуса и большой плюс, который их перекрывает. Минусы - преподы реально слабые и биоинформатика достаточно специфичное направление. Кстати в линуксе тоже биоинформатика, мать её. И плюс в том, что курс реально расчитан на зеленых и не опытных. Регаемся и начинаем задрачиваться, решаем задачи, смотрим видосы, вникаем и получаем сертификат.
  5. Параллеьно прохождению курса читаем книгу Марка Луца - Изучаем Python. Именно "изучаем", а не "программируем". Книгу советую читать параллельно курсу, т.е. выучили циклы на курсе, закрепили прочтением соответствующей главы в кинге. Не было в курсе какого-то понятия, а в книге есть - пропускаем, вернемся к нему дальше. На этом этапе нужно понять азы.
  6. Получили сертификат, теперь нужно закрепить и что-то кодить, идем на питонтьютор - http://pythontutor.ru/ и начинаем проходить задачки.
  7. Параллельно питонтьютору юзаем мобильное приложение - Solo learn https://play.google.com/store/apps/details?id=com.sololearn.python&hl=ru . В программировании нужна практика, поэтому чем больше прочитаете, напишите, обдумаете кода, тем лучше. Ближе к концу курса в приложении начнется дичь с ООП (объектно-ориентированное программирование), скорей всего ничего не поймете и сделать ничего не сможете, это ок:)
  8. Для того, чтобы получить хороший базис в ООП нужно пройти следующий курс опять же от команды stepik - https://stepik.org/course/512/syllabus . Это САМЫЙ ЛУЧШИЙ КУРС, который я проходил. Сэмвелл Тарли (нет, это просто препод, но очень похож)) ) в нем реально крут! Разложит по полочкам доступным языком (на сколько это возможно) что зачем и почему. Проходим курс, читаем кингу параллельно по тому же принципу и тыкаем приложение. По итогу получаем еще два сертификата - stepik и приложение и дочитанную книгу.
  9. Окей на этом этапе уже есть хорошее базовое понимание о том, что ждет, какие возможности у программирования в целом. Хочется больше практики, без неё никуда. Дальше влючается тяжелая артилерия - курсы от coursera. Для курсов у курсеры есть лайфхак. Не обязательно платить называется. Когда ты выбрал курс, читаешь описание, там есть ссылка "финаносвая помощь", переходишь, заполняешь, ждешь 2 недели и тебе открывают полный курс с получением сертификата в конце. Первый из них курс от Высшей Школы Экономики (Москва) - https://www.coursera.org/learn/python-osnovy-programmirovaniya . На рынке труда и в целом сфере обучения ВУЗ занимает хорошие позиции, а в твоем резюме явно лишним не будет сертификат от крупнейшей MOOC платформы с сертификатом этого универа. Этот курс я проходил первым. Т.е. ничего не знаю о питоне и пошел его проходить. Это был АД. Считаю, что курс все же по факту расчитан на хотя бы чуть-чуть понимающих людей. Зато в нем рассказывают про стилистику кода, PEP8 и другие плюшки, а так же отладку на PyCharm, хотя бы поверхностно.
  10. Получили крутой сертификат, дальше со всем этим багажом можно искать первые места работы на позицию джуна, пилить первые проекты в виде каких-нибудь ботов и прочее. Я начинал свой тернистый практический путь с того, что нашел на гитхабе проект, где чел замутил крутой скрипт для записи онлайн стримов. Окей, дальше этот проект я захотел объеденить с телегой. Эх, было время, но это другая история.
  11. По мимо просто курсов на coursera есть специализации. Это когда несколько курсов объеденены в специальность. Можно капнуть в сторону Python for everybody - https://www.coursera.org/specializations/python? . Он на английском, как мне в свое время сказали: "в английский надо уметь". На первых парах покажется очень легким, с учетом вашего багажа знаний, однако он затрагивает такие темы, как SQL, веб и прочее. Хотя в реальной жизни такие запросы, как показаны в курсе никто не пишет, надеюсь. Все используют расширения для питона, такие как peewee или sqlalchemy. Если знаний по базам данным вообще нет, то велком на stepik снова - https://stepik.org/course/1240/promo
В целом это все, как видите все знания можно получить совершенно бесплатно, главное усердно трудиться. Надеюсь этот пост поможет хотя бы одному человеку. Кстати здесь по питону тоже большое коммьюнити Python
Будут вопросы, с радостью отвечу в комментах или запилю еще пост, например, с полезнми ресурсами.
submitted by keepcalmandworking to Pikabu [link] [comments]

Моё разочарование в софте

Моё разочарование в софте

https://preview.redd.it/spfffhcplen31.png?width=349&format=png&auto=webp&s=600554cf45df5af3387c3fa56ad510ee08bf9a5f
Суть разработки программного обеспечения — Нужно проделать 500 отверстий в стене, так что я сконструировал автоматическую дрель. В ней используются элегантные точные шестерни для непрерывной регулировки скорости и крутящего момента по мере необходимости. — Отлично, у неё идеальный вес. Загрузим 500 таких дрелей в пушку, которые мы сделали, и выстрелим в стену.
Я занимаюсь программированием уже 15 лет. Но в последнее время при разработке не принято думать об эффективности, простоте и совершенстве: вплоть до того, что мне становится грустно за свою карьеру и за IT-отрасль в целом.
Для примера, современные автомобили работают, скажем, на 98% от того, что физически позволяет нынешняя конструкция двигателя. Современная архитектура использует точно рассчитанное количество материала, чтобы выполнять свою функцию и оставаться в безопасности в данных условиях. Все самолёты сошлись к оптимальному размеру/форме/нагрузке и в основном выглядят одинаково.
Только в программном обеспечении считается нормальным, если программа работает на уровне 1% или даже 0,01% от возможной производительности. Ни у кого вроде нет возражений. Люди даже гордятся, насколько неэффективно работает программа, типа «зачем беспокоиться, компьютеры достаточно быстрые»:
@tveastman: Я каждый день запускаю программу на Python, она выполняется за 1,5 секунды. Я потратил шесть часов и переписал её на Rust, теперь она выполняется за 0,06 секунды. Это ускорение означает, что моё время окупится через 41 год, 24 дня :-)
Наверное, вы слышали такую мантру: «Время программиста дороже времени компьютера». Это означает, что мы тратим компьютерное время в беспрецедентных масштабах. Вы бы купили машину с расходом 100 литров на 100 километров? Как насчёт 1000 литров? С компьютерами такое происходит постоянно.

Всё невыносимо медленно

Оглянитесь вокруг: портативные компьютеры в тысячи раз мощнее тех, что привели человека на Луну. Тем не менее, каждый второй сайт не может обеспечить плавную прокрутку страницы на 60 FPS на последнем топовом MacBook Pro. Я могу комфортно играть в игры, смотреть видео 4K, но не прокручивать веб-страницы! Это нормально?
Почтовому приложению Google Inbox в браузере Chrome от той же Google, требуется 13 секунд, чтобы открыть письмо среднего размера:

https://preview.redd.it/k5cdpjdtlen31.jpg?width=680&format=pjpg&auto=webp&s=d70dbcb010abdf306725fe81fce7f3feb0510185
Он ещё анимирует пустые белые формы вместо того, чтобы показать их содержимое, потому что это единственный способ анимировать что-то на веб-странице с приличной производительностью. Нет, не 60 FPS, а скорее «настолько быстро, насколько возможно на этой странице». С нетерпением жду, что же веб-сообщество предложит, когда дисплеи 120 Гц станут мейнстримом. Они еле справляются с 60 Гц.
Обновление Windows 10 занимает 30 минут. Что можно делать так долго? Этого времени достаточно, чтобы полностью отформатировать мой SSD-накопитель, загрузить свежий билд и установить его примерно 5 раз подряд.

https://i.redd.it/5ja7o7fylen31.gif
Павел Фатин: Набор текста в редакторе — относительно простой процесс, поэтому даже 286 могли обеспечить довольно плавный процесс набора.
В современных текстовых редакторах задержка при наборе больше, чем в 42-летнем Emacs. Текстовые редакторы! Что может быть проще? На каждое нажатие клавиши, нужно всего лишь обновить крошечную прямоугольную область на экране, а современные текстовые редакторы не могут сделать это за 16 мс. А это много времени. МНОГО. 3D-игра заполняет экран сотнями тысяч (!!!) полигонов за те же 16 мс, а также обрабатывает ввод, пересчитывает мир и динамически загружает/выгружает ресурсы. Как так?
Тенденция такова, что софт вовсе не становится быстрее и функциональнее. Мы получаем более быстрое оборудование, на котором софт с теми же функциями ворочается медленнее, чем раньше. Всё работает намного медленнее максимальной скорости. Никогда не задумывались, почему ваш телефон загружается от 30 до 60 секунд? Почему он не может загрузиться, скажем, за одну секунду? Здесь нет никаких физических ограничений. Лично мне бы такое понравилось. Хочется, чтобы разработчики достигли предела, используя каждый бит для производительности.

Всё ОГРОМНОЕ

И ещё это раздутие. Веб-приложения могут открываться в десять раз быстрее, если просто заблокировать рекламу. Google умоляет всех прекратить тормоза с помощью инициативы AMP — технического решения, для которого не нужны какие-либо технологии, просто немного здравого смысла. Если удалить раздувание, интернет станет работать на сумасшедшей скорости. Неужели это сложно понять?
Система Android без приложений занимает почти 6 ГБ. Просто задумайтесь на секунду, насколько неприлично огромное это число. Что там, фильмы в HD-качестве? Думаю, в основном код: ядро, драйверы. Ещё какие-то ресурсы, конечно, но они не могут быть такими большими. Сколько же драйверов вам нужно для телефона?

https://preview.redd.it/qcxx24c0men31.jpg?width=1100&format=pjpg&auto=webp&s=d06b4e43998ed1df28014aa2c7ff298642b541d0
Windows 95 занимала 30 МБ. Сегодня у нас есть веб-страницы тяжелее, чем эта ОС! Windows 10 уже 4 ГБ, то есть в 133 раза больше. Но разве она в 133 раза лучше? Я имею в виду, функционально они практически одинаковы. Да, у нас появилась Кортана, но я сомневаюсь, что она весит 3970 МБ. Но это Windows 10, неужели Android должен быть ещё в полтора раза больше?
Приложение клавиатуры Google как ни в чём не бывало съедает 150 МБ. Эта программа рисует 30 клавиш на экране — она правда в пять раз сложнее, чем вся Windows 95? Приложение Google app, в основном, просто пакет для Google Web Search, занимает 350 МБ! Сервисы Google Play, которыми я не пользуюсь (я не покупаю там книги, музыку или видео) — 300 МБ, которые просто сидят здесь и которые нельзя удалить.

https://i.redd.it/2vj4vbr3men31.gif
После установки всех необходимых приложений (социальные сети, чаты, карты, такси, банки и т. д.) на телефоне остался всего 1 гигабайт для фотографий. И это вообще без игр и музыки! Помните времена, когда ОС, приложения и все ваши данные помещались на дискету?
Ваша программа для заметок наверняка написана в Electron и, таким образом, поставляется с драйвером для контроллера Xbox 360, умеет показывать 3D-графику, воспроизводить аудио и фотографировать с помощью веб-камеры.

https://preview.redd.it/cg3r1igamen31.jpg?width=703&format=pjpg&auto=webp&s=13d9c86a5943f93ea55a6a5b1d0419ad609c77ad
Простой текстовый чат всегда славился скоростью и малым потреблением памяти. Так что Slack — это пример очень ресурсоёмкого приложения. Я имею в виду, что чат и текстовый редактор — это самые базовые вещи, они должны потреблять меньше всего ресурсов. Добро пожаловать в 2018 год.
Вы можете сказать, что они хотя бы работают. Но увеличение размера — не значит улучшение. Это значит, что кто-то потерял контроль. Мы больше не знаем, что происходит. Увеличение размера — это повышение сложности, снижение производительности и надёжности. Это ненормально и не должно считаться нормой. На раздутый размер нужно сразу обращать внимание — и держаться от них подальше.

Всё гниёт

Android-телефон на 16 ГБ был прекрасен три года назад. Сегодня под Android 8.1 он еле работает, потому что каждое приложение увеличилось минимум вдвое без видимых причин. Дополнительных функций нет. Они не стали быстрее и внешний вид не изменился. Они просто… раздулись?
iPhone 4s вышел с iOS 5, но едва может работать под управлением iOS 9. И это не потому, что iOS 9 намного лучше — в основном, система не изменилась. Но новое оборудование быстрее, поэтому они сделали программное обеспечение медленнее. Не волнуйтесь — вы получили захватывающие новые возможности, например… работа тех же приложений с той же скоростью! Не знаю.
iOS 11 прекратила поддержку 32-разрядных приложений. Это значит, что если разработчик не готов вернуться и обновить приложение, скорее всего, вы не увидите снова эту отличную программу.
@jckarter: Программу DOS можно заставить работать без изменений практически на любом компьютере, сделанном после 80-х годов. Приложение JavaScript может прекратить работу из-за завтрашнего обновления Chrome.
Сегодняшние веб-страницы не будут работать в любом браузере через 10 лет (а может и раньше).
«Нужно бежать со всех ног, чтобы только остаться на том же месте». Но смысл? Я могу постоянно покупать новые телефоны и ноутбуки, как все, но делать это лишь ради того, чтобы иметь возможность запускать все те же приложения, которые стали только медленнее?
Думаю, что мы можем и должны исправить ситуацию. Сейчас все разрабатывают программы для сегодняшнего дня, изредка для завтрашнего. Но будет неплохо делать вещи, которые работают немного дольше.

Хуже — значит лучше

Сейчас никто ничего не понимает. И не хочет понимать. Мы просто выпускаем полусырую ерунду, надеемся на лучшее и называем это «здравым смыслом для стартапа».
Веб-страницы просят обновиться, если что-то пошло не так. У кого есть время, чтобы найти причину неполадки?

https://preview.redd.it/o4qe045imen31.jpg?width=1200&format=pjpg&auto=webp&s=58f8ff4634c0757f86c0f1b7c4b666dc1477600d
Любое веб-приложение выдаёт постоянный поток «случайных» ошибок JS, даже на совместимых браузерах.
Вся архитектура баз данных веб/SQL построена на предпосылке (даже надежде), что никто не изменит данные, пока вы смотрите на открытую веб-страницу.
Большинство приложений для совместной работы сделали «как смогли», там масса типичных сценариев, когда они теряют данные. Видели диалог «Какую версию сохранить?» Сегодня планка так низка, что пользователи рады даже этому вопросу.

https://preview.redd.it/i1ahkqplmen31.jpg?width=750&format=pjpg&auto=webp&s=fd81795e60cfed5c76c86d0cce051d89f708403d
И нет, в моём мире не является нормальным приложение, которое говорит: «Я уничтожу часть твоей работы, только выбери какую».
Linux намеренно убивает случайные процессы. И всё же это самая популярная серверная ОС.
У меня каждое устройство регулярно выходит из строя так или иначе. Время от времени монитор Dell нужно аппаратно перезагружать, потому что в нём есть софт. AirDrop? Вам повезёт, если он обнаружит устройство, иначе что делать? Bluetooth? Спецификации настолько сложны, что устройства не будут устанавливать связь друг с другом, а периодические перезагрузки — оптимальный вариант.

https://preview.redd.it/8sag8qvomen31.jpg?width=1200&format=pjpg&auto=webp&s=57f822c831f2e2c10fe8a3374791c005b2f22529
И я даже не упоминаю об Интернете вещей. Это настолько за гранью разумного, что даже нечего добавить.
Я хочу гордиться своей работой. Я хочу делать рабочие, стабильные вещи. Для этого нужно понять, что конкретно мы разрабатываем, внутри и снаружи, а это невозможно сделать в раздутых, чрезмерно усложнённых системах.

В программировании такой же хаос

Кажется, что никто больше не заинтересован в качественных, быстрых, эффективных, долговечных, основательных решениях. Даже если давно известны эффективные решения, мы по-прежнему боремся с теми же проблемами: управление пакетами, системы сборки, компиляторы, конструкция языка, IDE.
Системы сборки по своей сути ненадёжны и периодически требуют полной очистки, хотя у них есть вся информация для инвалидации. Ничто не мешает сделать процесс сборки надёжным, предсказуемым и на 100% воспроизводимым. Просто никто не думает, что это важно. NPM уже много лет находится в состоянии «иногда работает».
@przemyslawdabek: Кажется, что rm-rf node_modules является неотъемлемой частью рабочего процесса в проектах Node.js/JavaScript.
А время сборки? Никто не считает проблемой, что компилятор работает минуты или даже часы. А как же «время программиста дороже»? Почти все компиляторы, пре- и постпроцессоры значительно, иногда катастрофически увеличивают время сборки, не обеспечивая пропорционально существенных преимуществ.

![img](3wvw659xmen31 " Вы ожидаете, что программисты будут принимать в основном рациональные решения, но иногда они делают прямо противоположное. Например, выбирая Hadoop даже если он медленнее, чем выполнение той же задачи на одном десктопном компьютере. ")
Машинное обучение и ИИ отбросили программное обеспечение к гаданию на кофейной гуще во времена, когда большинство компьютеров даже не были достаточно надёжными.
@rakhim: Когда приложение или сервис говорит «под управлением ИИ» или «на основе машинного обучения», я читаю это как «ненадёжное, непредсказуемое поведение, которое не поддаётся объяснению». Я держусь подальше от «ИИ», потому что хочу от компьютеров противоположного: надёжности, предсказуемости и логики.
Мы засунули виртуальные машины в Linux, а затем засунули Docker в виртуальные машины, просто потому что никто не смог разобраться с бардаком, который производят большинство программ, языков и их окружений. Мы накрываем дерьмо одеялами, чтобы не убирать его. Например, «единый бинарник» остаётся ОГРОМНЫМ преимуществом Go. Нет бардака == успех.

https://preview.redd.it/hfhlxty3nen31.png?width=492&format=png&auto=webp&s=5264df9b75138f827dda279e1a7d3ef361ba7b90
Окружающая среда Python настолько загрязнилась, что мой ноутбук объявили зоной экологической катастрофы. Примечание. Агентство по защите окружающей среды Python хотело залить его цементом и захоронить с картинкой на входе — предупреждением для будущих цивилизаций об опасности использовать sudo для установки случайных пакетов
А зависимости? Люди бездумно ставят переусложнённые «полные пакеты» для простейших проблем, не думая о последствиях. Из этих зависимостей растут новые. В конечном итоге вы получаете дерево, которое является чем-то средним между фильмом ужасов (огромное и полное конфликтов) и комедией (нет причин, по которым мы добавили сюда эти пакеты, но вот они):

https://i.redd.it/vugj7kn5nen31.gif
Программы не могут работать несколько лет без перезагрузки. Иногда даже несколько дней — это слишком. Происходят случайные глюки, и никто не знает почему.
Что ещё хуже, ни у кого нет времени остановиться и выяснить, что произошло. Зачем беспокоиться, если всегда есть другой выход. Поднять новый инстанс AWS. Перезапустить процесс. Удалить и восстановить базу данных. Написать скрипт, который будет перезапускать ваше сломанное приложение каждые 20 минут. Включить одни и те же ресурсы несколько раз: тяп-ляп — и в продакшн. Двигайся быстро, не трать время на исправление ошибок.
Это не инженерная работа. Это просто ленивое программирование. Инженерная работа предполагает глубокое понимание производительности, структуры и ограничений того, что вы создаёте. Лепить халтуру из некачественного материала — совершенно противоположное занятие. Чтобы развиваться, мы должны понимать, что и зачем мы делаем.

Мы застряли

Таким образом, всё это просто куча едва работающего кода, добавленного поверх ранее написанного едва работающего кода. Он продолжает расти в размерах и сложности, уменьшая шансы на изменения.
Чтобы иметь здоровую экосистему, необходимо вернуться. Необходимо иногда выбрасывать хлам и заменять его лучшими альтернативами.

https://preview.redd.it/iznyolw8nen31.jpg?width=984&format=pjpg&auto=webp&s=31ad389fe2e259935354be637367488015dc13a1
Но у кого есть на это время? Новые ядра ОС не выходили сколько, 25 лет? Это сейчас стало слишком сложным, чтобы просто взять и переписать. В браузерах накопилось столько пограничных ситуаций и исторических прецедентов, что никто не осмелится писать движок с нуля.
Сегодняшнее определение прогресса — или подбросить топлива:
@sahrizv: 2014 — нужно внедрить микросервисы для решения проблем с монолитами. 2016 — нужно внедрить Docker, чтобы решить проблемы с микросервисами. 2018 — нужно внедрить Kubernetes, чтобы решить проблемы с Docker.
или изобретать велосипед:
@dr_c0d3: 2000: напишите 100 строк XML, чтобы «декларативно» настроить сервлеты и EJB. 2018: напишите 100 строк YAML, чтобы «декларативно» настроить микросервисы. В XML были хотя бы схемы…
Мы застряли, и никто нас не спасёт.

Бизнесу всё равно

Пользователям тоже. Они выучились принимать то, что мы делаем. Мы (инженеры) говорим, что каждое приложение для Android занимает 350 МБ? Хорошо, они будут с этим жить. Мы говорим, что не можем обеспечить плавную прокрутку? Окей, они свыкнутся с телефоном, который подтормаживает. Мы говорим: «Если не работает, перезагрузитесь»? Они перезагрузятся. Ведь у них нет выбора.
Конкуренции тоже нет. Все строят одни и те же медленные, раздутые, ненадёжные продукты. Случайный скачок вперёд по качеству даёт конкурентное преимущество (iPhone/iOS против других смартфонов, Chrome против других браузеров) и заставляет всех перегруппироваться, но ненадолго.
Наша миссия как инженеров — показать миру потрясающие возможности современных компьютеров с точки зрения производительности, надёжности, качества и удобства использования. Если нам не всё равно, люди потянутся. И никто кроме нас не покажет им, что такое возможно. Если только нам не наплевать.

Не всё так плохо

Иногда на пасмурном небосводе просвечивают лучики надежды.
Работа Мартина Томпсона (LMAX Disruptor, SBE, Aeron) впечатляет, она освежающе проста и эффективна.
Редактор Xi Рафа Левиена, кажется, построен на правильных принципах.
Джонатан Блоу для своей игры разработал язык компилирования, который компилирует 500 000 строк в секунду на ноутбуке. Это холодная компиляция, никакого промежуточного кэширования, никаких инкрементальных билдов.
Не нужно быть гением, чтобы писать быстрые программы. Здесь нет какой-то магии. Единственное, что требуется, — это не строить софт на базе огромной кучи дерьма, которую поставляют современные инструменты.

Манифест лучшего мира

Я хочу видеть прогресс. Я хочу перемен. Чтобы современное программное обеспечение совершенствовалось, а не стояло на месте. Я не желаю заново изобретать одно и то же, каждый раз выпуская всё более медленный и раздутый продукт. Я хочу во что-то верить — в достойную цель, в будущее, которое лучше, чем то, что мы имеем сегодня, и чтобы появилось сообщество инженеров, которые разделяют это видение.
Что мы имеем сегодня — это не прогресс. Мы едва достигаем бизнес-целей с этими плохими инструментами. Мы застряли в локальном оптимуме, и никто не хочет двигаться. Это даже не хорошее место, оно раздутое и неэффективное. Мы просто как-то привыкли к нему.
Поэтому я хочу заявить: нынешняя ситуация — полное дерьмо. Как инженеры, мы можем и должны, и сделаем лучше. У нас могут быть лучшие инструменты, мы можем создавать лучшие приложения, более быстрые, предсказуемые, более надёжные, использующие меньше ресурсов (на порядки меньше!). Мы должны глубоко понять, что мы делаем и почему. Мы должны выпускать продукты надёжно, предсказуемо, с самым высоким качеством. Мы можем и должны гордиться нашей работой. Не просто «учитывая то, что у нас было...» — никаких оговорок!
Надеюсь, я не одинок. Надеюсь, что есть люди, которые хотят того же. Я буду рад, если мы хотя бы начнём говорить о том, насколько абсурдно нелепа нынешняя ситуация в индустрии программного обеспечения. А потом, возможно, придумаем, как выбраться из неё.
Автор оригинала: Nikita Prokopov
submitted by 5igorsk to Tay_5 [link] [comments]

Exception: родственник goto

Exception: родственник goto
Внимание: содержание этого поста может показаться "дичью". Утверждения в посте могут восприниматься как категоричные ("это единственно правильный путь"), но на самом деле это не так. Все, написанное здесь - мое субъективное мнение и я могу ошибаться. Как описано здесь, пост написан для обсуждения, поэтому если у вас есть хорошие аргументы как "против", так и "за" - добро пожаловать в комментарии.

https://preview.redd.it/6ay8tqf6dr041.png?width=1216&format=png&auto=webp&s=003921aa198298176a7700ae6f407c61cf92cddc

Исключения (Exceptions) - это настолько распространенный инструмент, что предложение "не использовать исключения" может показаться абсурдным, как например предложение "не использовать массивы". Исключения - базовый компонент любого мейнстрим языка, вполне логичный, легкий для изучения и применения. Как вообще может появится мысль не использовать их? Все дело в точке зрения. Если задача - написать код, чтобы он делал Х - то исключения действительно отличный инструмент, разве что может быть несколько затратный. Если же задача не только написать код, чтобы он делал Х, но и постепенно этот код "эволюционировать": чтобы делал "Х", а иногда еще и уведомлял нужных людей, а в некоторых случаях чтобы сначала подождал подтверждения от этих людей, и только потом делал "Х" - тут можно увидеть неудобства, которые вызывают исключения.

(Выдуманный) случай из жизни

Как сказано в заголовке, exception - это родственник goto. Такое утверждение может вызвать протест, все мы знаем и любим исключения, а goto - общеизвестное фу-фу, как можно их сравнивать? Но если убрать эмоции то утверждение вполне себе справедливое. Goto позволяет переместить выполнение программы на какую-то метку, exception - вверх по стеку (если непонятно, что это значит - задайте вопрос в комментариях, напишу про это). Технически return - это тоже родственник goto и очень близкий родственник exception, но с очень ограниченными правами. Почему это нехорошо? В целом по тем же причинам, почему и goto не очень хорош (есть и другая точка зрения): вместо предсказуемого выполнения ваша программа может продолжить работу в любом месте выше по стеку. Возьмем, к примеру, Аню, которая работает над enterprise проектом. При тестировании свежереализованной функциональности Аня получает следующий stacktrace (курсивом - рассуждения Ани):
corp.e.store.ItemNotFoundException: Item with SKU #13423 is currently out of stock at corp.e.store.ItemRepository.reserveItem(ItemRepository.java:425) at corp.e.store.ItemManager.reserveItems(ItemManager.java:587) at corp.e.store.OrderProcessor.reserveItems(OrderProcessor.java:781) at corp.e.store.OrderProcessor.processPrepaidOrder(OrderProcessor.java:443) at corp.e.store.OrderProcessor.processOrder(OrderProcessor.java:317) 
Ага, приложение падает, если такой товар недоступен на складе. На каком из этих уровней нужно добавить обработку исключения? На ItemManager.reserveItems? Логично, ведь в заказе может быть несколько вещей, и если другие доступны мы хотим их обработать. Или может быть на уровне OrderProcessor.reserveItems? Хотя на уровне OrderProcessor.processPrepaidOrder было бы удобнее - заказ предоплачен, и наверное нужно вернуть клиенту часть денег. Или можно обработать на уровне processOrder и вообще отменить заказ и вернуть клиенту всю предоплату (в этом случае мы заодно обработаем все сценарии заказов: и с предоплатой, и без). По-хорошему, конечно, нужно бы во всех этих местах сделать обработку, но функционал уже через пару должен быть сдан и на сегодняшний день мы точно знаем, что наш клиент хочет либо весь заказ, либо ничего (потому что клиент - соседний отдел). Поэтому пока сделаем обработку на уровне OrderProcessor.processOrder, а вдругих местах будем добавлять по мере надобности.
Рассуждения весьма обоснованы, и выбранное решение хотя возможно и не самое лучшее с точки зрения качества кода, но зато сбалансированное с точки зрения потребностей бизнеса. Тем не менее это решение, к сожалению, создает предпосылки для достаточно неприятных проблем с эволюцией проекта. Посмотрим, что будет происходить дальше.
Функционал был запущен в срок и работал как часы. Через некоторое время другой разработчик на проекте, Борис, получает задание адаптировать этот функционал под потребности нового внутреннего клиента: если в заказе отсутствуют некоторые товары, то их можно убрать из заказа, уведомив об этом определенных людей, и обработать только те товары, которые есть:
Такс, мне нужно по-разному обрабатывать случаи, когда товара нет в наличии. В некоторых случаях - отменять заказ вообще, в некоторых - записывать чего именно не было и продолжать. Изменения можно внести либо в OrderProcessor.reserveItems, либо в ItemManager.reserveItems. Наверное лучше будет изменить ItemManager: давайте добавим параметр OutOfStockItemsHandlingStrategy, который пока что будет либо CancelWholeOrder или SkipOutOfStockItems. Тогда, соответственно, мы будем ловить ItemNotFoundException на уровне ItemManager, и дальше если стратегия SkipOutOfStockItems - будем продолжать обработку, если CancelWholeOrder - то наверное стоит выбросить уже другое исключение. Создадим свежее: ItemReservationException, каким его сделать: Exception или RuntimeException? Какой тип наследует ItemNotFoundException? RuntimeException - окей, значит, для консистентности, и наше новое исключение будет RuntimeException. Плюс еще поменять возвращаемый тип - теперь нам нужно вернуть не id забронированных товаров, но и список тех товаров, для которых бронирование не удалось. Окей, готово. Блин, еще в 5 местах используется ItemManager, но это ок, рефакторинг несложный: добавим всем стратегию CancelWholeOrder подправим, чтобы работало с новым типом возвращаемых данных. Окей, готово, можно отправлять на ревью. Стоп, падают тесты, что там такое? А, OrderProcessor.processOrder раньше ловил ItemNotFoundException, а теперь нужно его поменять на ItemReservationException (хорошо, что был тест, не хотелось бы, чтобы эту проблему обнаружили пользователи). Теперь готово.
На этом примере уже лучше видна проблема с goto / исключениями. Т.к. обработка может происходить на любом уровне, есть вероятность, что при изменениях какие-то обработки "потеряются". Здесь может возникнуть вполне обоснованный аргумент: именно поэтому лучше использовать не RuntimeException, а просто Exception (разница между ними в том, что Exception обязан декларироваться в сигнатуре метода и тот, кто этот метод вызывает обязан это исключение обрабатывать):
public class ItemManager { public List reserveItems(List itemIds) throws ItemReservationException { ... } } 
Что ж, это справедливый аргумент, правда у такого решения есть свои последствия:
  • Сигнатуры методов становятся длиннее
  • Весь код, вызывающий методы должен обрабатывать эти исключения
Эти последствия хоть и неприятны, т.к. добавляют много одинакового кода, но на самом деле очень даже полезны:
  • Метод явно указывает, что может пойти не так
  • Вызывающий код обязан уметь реагировать на ошибки
Предположим, что третий разработчик в команде, Виктория, как раз задумалась над повышением качества кода:
Неплохо было бы изменить все проектные RuntimeExceptions на Exceptions, тогда каждый, кто вызывает ItemManger будет должен решить что делать со случаями, когда один из товаров отсутствует. Хотя тут возникает вопрос: а почему ситуация отсутствия товара на складе считается исключительной? Одно дело, когда вдруг связь с серверами склада прерывается - это действительно исключительная ситуация, но ситуация отсутствия товара - вполне ожидаема. Не лучше ли сделать ItemReservationResult, в котором будет содержаться либо ItemReservationId, либо причина, почему бронирование не удалось?
В этом случае заметна еще одна особенность исключений - исключение это такой особенный return. Только если в случае обычного возвращаемого значения мы используем полиморфизм, if или switch, чтобы решить, что делать дальше, то в случае исключений мы должны использовать try - catch - (finally).

Таким образом

А) С исключениями вы можете отложить обработку проблемных ситуаций "на потом". Причем даже не просто "можете", а по-умолчанию предлагается именно так и делать, если только не настроены специальные инструменты, которые будут заставлять избегать использования RuntimeException. Это плохо, потому что изначально в дизайн и API не закладываются ситуации с ошибками, и когда эти ситуации обнаруживаются приходится "ввинчивать" обработку туда, где она нужна. Как известно чем позже обнаружена проблема, тем дороже ее исправить, т.е. если это API библиотеки или сервиса, который уже используется - изменения могут занимать недели.
Б) Программирования для случая, когда все идет как надо и нет ошибок - это кредит, и расплачиваться по нему приходиться либо вам через некоторое время после написания кода, либо вашим коллегам.
В) При работе с исключениями вам нужно принимать много решений, которые вообще никакого отношения не имеют к тому, что вы создаете:
  • На каком уровне обрабатывать исключение?
  • Exception или RuntimeException?
  • Пользоваться стандартными исключениями, создать свои общие для всего (обычно это добро лежит в пакете common или util), или же свои специфичные для нашего проекта? Если свои - то свое на каждый случай или на каждый пакет / сервис с enum внутри, чтобы тип определять?
  • Какие имена придумать всем этим исключениям? Хотя нет, от этого никуда не деться, с исключениями вы пишете или без.
  • Данный случай - это исключение или это допустимый случай, и ошибки должны возвращаться через возвращаемое значение?
Помимо того, что совершенно невозможно разработать единый стиль по всем этим вопросам (потому что в этом нет никакого смысла), так еще и велик шанс, что в каком-то из этих пунктов мнение разработчиков в команде разойдется и привет споры про то, что лучше: табы или пробелы.

Какая альтернатива?

Но если не исключения, то как? Ответ прост: возвращать ошибки через возвращаемое значение. Есть два примера:
Говорят, что в функциональных языках только так и делается - возвращаемое значение будет либо собственно, значением, либо ошибкой, причем это самое значение само будет обрабатывать и тот и тот случай. Но я, к сожалению, не разбираюсь в функциональном программировании, поэтому может быть что это и вообще не так (знающие люди - напишите пожалуйста как оно устроено).
Стоит ли вообще никогда не использовать исключения? Наверное, нет. Исключение хорошо подойдет для случая, когда дальнейшая работа программы не имеет смысла. Если же смысл продолжать работу есть, то ошибка - это одно из возвращаемых значений.
submitted by yb172 to Pikabu [link] [comments]

Шпионское приложение для видеокамер Panasonic

Шпионское приложение для видеокамер Panasonic
Наверное жители сообщества Пикабу уже соскучились по бизнес-историям, которые некогда я так рьяно начал постить на Reddit-е :-) Но нет - сегодня я решил исправиться всецело, так сказать - решил выложить текстовый пост. И тема в нём пойдёт о некотором небольшом, но весьма полезном приложении (для десктопа, ноута или прочего производного архитектуры x86_64), которое автору данного текста пришлось разработать для нужд его видеоблогерской деятельности. И к стати да, скачать его можно с общеизвестного хостинга открытого программного обеспечения, отсюда: https://panrc.sourceforge.io/

Panasonic Camera Remote Control (Russian Locale)
Итак, с ходу: что за приложение?
Приложение, которое даёт возможность управлять видеокамерой Panasonic с ноута или стационарного компьютера через сеть Wi-Fi. Функционал приложения достаточно скудный: можно дистанционно стартовать или останавливать запись видео, приближать, удалять и просматривать видеопоток с камеры (имитация видоискателя). Этот минимум был мне необходим для того, чтобы перестать использовать веб-камеру для моего видеоблога на Ютубе (https://youtube.com/HITRome) и перейти на более-менее нормальную камеру Panasonic HC-X920, у которой я уже давно засматривался на заветную кнопочку "Wi-Fi"...
Само приложение написано на Java, поэтому им можно пользоваться как на Linux, Windows, так и MAC OS. А вот так просто запустить на мобильном устройстве эту программу не получится. Но, на сколько я знаю, для мобильных устройств у Panasonic есть своя утилита удалённого управления.
Область применения этой "дистанционки" достаточно обширна: можно как я - установить куда-никуда (я ставлю на полочку, которая находится у меня на столе), подложить пару десятирублёвых монет и снимать себя любимого (например, для видеоблога); можно установить камеру на окно или на балкон, и наблюдать, например, что творится ночью в определённой квартире соседского дома напротив, параллельно записывая особо удавшиеся эротические сцены на флешку ;-)) Или использовать камеру для безобидного наблюдения за своими чадами из кухни, особенно, например, когда дочка пригласила в гости молодого человека - ну, дабы предотвратить вовремя последствия.. Или в качестве видео-радио-няни - тоже как вариант.. В общем, область применения приложения достаточно обширная - полёт фантазии может быть ограничен только моральными принципами.
Немного исторических предпосылок и наглядное использование приложения PanRC представлено в достаточно длинном (около 25-и минут) видеоролике: https://youtu.be/7HsINzJL5Bs
Для того, чтобы нормально стартануть программу, нужно, чтобы на компьютере стояла Java (Java SE версии как минимум 8 - взять можно отсюда: https://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html ) и ещё, нужно через меню камеры войти в режим дистанционного управления, подсоединиться с компьютера или ноутбука к образовавшейся сети Wi-Fi и определить адрес камеры, который (обязательно вместе с маской подсети!) ввести в стартовый интерфейс приложения:
Panasonic Camera Remote Control (Russian Locale) - starting graphic interface
Но в видеоролике я допустил неточность, когда рассказывал о способе определения IP-адреса камеры, подключенной к компьютеру через Wi-Fi. Дело в том, что моя камера образует сеть Wi-Fi и при подключении устройства даёт IP-адрес всегда определённый, хотя другие видеокамеры могут его динамически менять. Кроме того, само подключение к сети Wi-Fi камеры должно происходить с аутентификацией по паролю (в настройках камеры это нужно выставить, чтобы камера предоставляла автоматически сгенерированный пароль). Иначе утилита просто не сможет работать с видеокамерой (там нужно при подключении камеры использовать UPnP для получения разрешения передавать информацию по сети). По этому поводу подробную информацию можно почерпнуть из другого 10-минутного видеоролика: https://www.youtube.com/watch?v=rYKb69IDo3k
Ну вот такое, возможно кому-то очень полезное, приложение получилось у меня сваять... Сейчас на SourceForge находится beta-версия, которая вполне рабочая, хотя и не очень хорошо оттестированная на камерах отличных от моей HC-X920. Вижу, что народ интересуется, люди скачивают, но обратной связи я до сих пор так и не получил. Сам пытался у друзей посредством этой утилитки управлять их моделями Panasonic и обнаружил такой баг: при подключении камера может проинициализироваться, но приложение этого может "не заметить" и откатиться в стартовый интерфейс ввода IP-адреса и маски подсети. Повторное нажатие на кнопку "Соединить с камерой" восстанавливает ситуацию - после этого появляется интерфейс управления и превью. Если превью нет - смотрим на маску подсети: в большинстве случаем она такая: 255.255.255.0.
В заключение хочу кратко рассказать о перспективах проекта. Как я уже говорил в видеороликах - в принципе, мне функционала достаточно. Единственное, не хватает индикации свободного места на флеш-носителе - это, возможно, будет реализовано в следующем релизе. Сейчас же урывками тружусь над нормальной (не бета) версией, в которой будут пофиксины те два тикета, которые сейчас имеются на SourceForge (которые я же сам и завёл :-)) ). И можно было бы проект развивать дальше: например, сделать режим съёмки фото, просмотра и управления отснятым видеоконтентом с возможностью удаления и копирования по сети.. Но пока я проявления особого интереса к проекту не наблюдаю... Поэтому, скорее всего, сделаю только намеченные улучшения.
Самой программой можно пользоваться бесплатно. После выпуска финальной версии приложения я выложу исходники (в них надо ещё поднавести порядок :-) ).
Если кому захочется сказать "спасибо" и таким образом поощрить и простимулировать развитие этого проекта или разработку другого открытого программного обеспечения, всегда это можно сделать, например, купив разработчику чашечку кофе здесь: https://ko-fi.com/hitrome или просто подписаться на мой YouTube-канал: https://youtube.com/HITRome
submitted by RomeHIT to Pikabu [link] [comments]

"Что подарить девушке?" и к чему это приводит.

Недавно получил довольно интересный жизненный опыт и решил, что эта история достойна пикабу.
Примерно пол года назад я размышлял что подарить девушке на 14 февраля. Ничего из материального мира не лезло мне в голову, поэтому было принято решение подарить эмоции и коробочку рафаэлок. Ещё до этого, на просторах интернета, я видел статейку, о том как парень устроил девушке персональный городской квест. Идея мне эта понравилась и настал идеальный момент чтобы воплотить её в жизнь.
Первая мысль была, что неплохо бы использовать для квеста какое-нибудь приложение. Сейчас ведь есть приложения для всего.
https://preview.redd.it/neu53jxcsel31.jpg?width=644&format=pjpg&auto=webp&s=7b968f9b6cb9010fe19dfeb97367ec136b9b29ea
В одной из первых строк поиска мне выдало статейку с рассказом парня о том, как он решил создать приложение для квестов и вдохновением послужило желание сделать квест для девушки. Где-то я уже это слышал… Чёрт, да это же я.

https://preview.redd.it/uduf326gsel31.jpg?width=603&format=pjpg&auto=webp&s=320237c9aba9faf0fbb1383f5e56404230aa43cd
Хотя нет, я ещё ничего не создал. Ну ладно.
Я сразу же скачал это приложение, но к моему разочарованию, создать в нём квест мне так и не удалось. Возможно данный функционал не был основным и был спрятан глубже в приложении, либо часть с созданием квеста была платной, в общем как создать квест я так и не разобрался. В общем, к моему удивлению я так и не нашёл ничего подходящего. 14 февраля было уже на носу, поэтому на собрании со своими мыслями было принято решение сделать квест по старинке - на бумажках. К счастью квест прошёл на ура, а вот мысль, о создании приложения для квеста проходить не собиралась и крепко засела у меня в голове.
После недолгих раздумий я решил, что интересно будет попробовать написать приложение самому. Задачу усложнял тот факт, что я никаким боком не программист и в школе на информатике просиживал штаны играя во флеш игры. Мои знания о программировании ограничивались функцией if в экселе. К счастью мы живём в 21 веке и вокруг полно легко доступной информации и мемасиков про сложность программирования. В гугле я разузнал что нужно на первых этапах для написания мобильного приложения под андроид. Оказалось не так уж много: среда для разработки Android Studio и знание языка программирования Java (как потом выяснилось есть ещё альтернативный язык Kotlin). С установкой Android Studio я разобрался довольно быстро. Теперь мне предстояло разузнать что же такое эта Java.

https://preview.redd.it/grzi72pksel31.jpg?width=591&format=pjpg&auto=webp&s=2fafac4b4095c2d0cf199e57041b07f1c24a945f

https://preview.redd.it/vms28sqlsel31.jpg?width=602&format=pjpg&auto=webp&s=a80e85a9662e5745acea90802c8479b7adc3c89c

https://preview.redd.it/mo8xzjlmsel31.jpg?width=589&format=pjpg&auto=webp&s=914393cf08cccdbbe820de6f4030ac3c988908b0
С этим мне отлично помог Ютуб. Вдоволь насмотревшись видео в стиле “Разработка под андроид для начинающих” я осознал несколько вещей: надо было учиться информатике в школе, писать код с нуля без знания теории будет сложно, большая часть видосиков про андроид разработку создано индусами.
Пришло время понять чего я хочу от своего приложения. На первых этапах я подумал что хватит просто создать приложение на один раз, для себя. Так как я собирался создавать квест с привязкой к геолокации, то было принято решение просто вбить статичные координаты точек на карте в сам код приложения, без возможности их менять. Такое простое приложение-квест по моим потребностям.
Структуру можно представить так:
1.Приложение показывает пользователю текущую задачу, например: место первого свидания.
2.Пользователь сам разбирается куда нужно идти без подсказок в виде координат на карте.
3.По достижению нужного места приложение выдаёт описание следующей точки.

Даже после всех тех сложностей, которые мне обещали видео с ютуба, мне казалось, что такое приложение написать будет по силам. Перед написанием кода, я решил почитать литературу по Java. Это рекомендовали сделать почти все видео на ютубе, но какую книгу я бы не брал, через несколько страниц я понимал, что мне не интересно и скорее всего это не пригодится, так как я не собирался становиться Java разработчиком.
И так я приступил к написанию кода с помощью множества уроков на ютубе. Поначалу я не понимал что говорят в видео и просто повторял действия, но со временем, я всё так же не понимал что я делаю. После того как не имея бэкапа я удалил 20 часов своей работы, я осознал важность бэкапов. Но мой код понемногу писался и я был доволен собой. После того как я наконец заставил смартфон показывать на экране свои координаты, я ощутил себя крутым программистом.
https://preview.redd.it/o9iltxiqsel31.jpg?width=599&format=pjpg&auto=webp&s=900349e1ac0d88a49c42bb490eb82665ad107dbb
Хотя дальше меня ждало ещё много неожиданностей, о которых я даже не подозревал. В итоге, программа оказалась сложнее чем я рассчитывал, так как многие аспекты изначально не были учтены.
Примерно через месяц с начала написания первой строчки кода, я уже мог использовать приложение по назначению. Но в моей голове уже зародились наполеоновские планы: “А что, если сделать это приложение общедоступным и запихнуть в него не один квест, а несколько, и ещё добавить парочку экскурсий, и сделать это для разных городов, и на разных языках, и чтобы оно лечило рак, и помогало зачать ребёнка?”
И так, я решил создать приложение не только для себя, но и для других, и заработать кучу денег.
Первая идея была создать набор с квестами и экскурсиями. Но от неё я быстро отказался, так как таких приложений было полно и она были явно лучше чем то, что я мог создать. Тогда я вспомнил для чего изначально писалось приложение: чтобы пользователь мог сам создать квест. За работу. На этом этапе программирование стало сложнее, было трудно находить нужную инфу на ютубе, пришлось начать понимать, что я делаю и что делает код, который я пишу.

https://preview.redd.it/vvono62tsel31.jpg?width=436&format=pjpg&auto=webp&s=6d6b2269bf4791034c21132745c6fe997f192bc7
Кодил я в основном на выходных и иногда после работы. Хотя бывали перерывы до двух недель, когда мне надоедало. Я не устанавливал для себя каких-то целей и дэдлайнов. Через пол года идея превратилась в реальность. Приложение получилось со своими косяками и недоработками, некоторые детали хотелось сделать иначе, но недостаток знаний в языке даёт о себе знать. В конечном варианте приложение справляется со своей прямой функцией создания квестов с последующим их прохождением, что мне и было нужно, и еще пользователи могут делиться квестами. Позже было решено прикрутить к приложению немного рекламы.
Дальше меня ждал монстр, о котором я даже не подозревал - Google Play. Оказалось, что поделиться приложением с миром не так-то просто. Нужно заполнить кучу разных данных, создать политику конфиденциальности и долго ждать, пока приложение проходит проверку гугла. И наконец, после всех проверок, приложение появилось в Play Store. Только была одна маленькая пробелма.... о приложении никто не знал и оно никому не было нужно. Было смешно так как оно даже не отоброжалось в поиске, его удавалось найти только введя мой юзернейм в поиск. Блииин, а как же все те доллары, которые мне обещала моя фантазия...
Так я понял, что без анализа потребностей рынка, не стоит лишний раз двигать жопкой. Хотя это приключение мне вполне понравилось, да и теперь если я забыл купить подарок девушке, я всегда могу быстро сделать ей городской квест и приятно провести время.
https://preview.redd.it/3qvor2susel31.jpg?width=498&format=pjpg&auto=webp&s=a3ed13e80e55735b15715996fdaeb58a0881430a
Спасибо за внимание.
submitted by Artimilion to Pikabu [link] [comments]

1996 Андрей Ache Чернов. Интервью журналу "Мир Интернет"

1996 Андрей Ache Чернов. Интервью журналу
Ache666 1996

Профессионал


Андрей родился в 1966 году, закончил Московский государственный университет по специальности "прикладная математика". Живет в Москве. Участвовал в следующих проектах: Taylor UUCP, PGP, Elm, Tin, Lynx, UUPC/@, FreeBSD, Mail/@, NCFTP, ZIP/UNZIP, Less, Speak Freely, SSH (Secure Connections). Автор RFC-1489 ("регистрация кодировки KOI8-R"). Его интересы: магия, философия, психотерапия, альтернативная музыка.
Андрей, существует мнение, что Internet в России отстает от штатовского на несколько лет. В США развитие Internet проходило три стадии: проникновение в научные образовательные организации, в бизнес и коммерцию, и, наконец, доступность широким слоям населения. Мы, похоже, находимся на второй стадии этого развития, когда Internet становится интересен для бизнеса. Я бы не стал так опрометчиво переносить модель американского развития Internet сюда в Россию. Дело в том, что в каждой стране существуют национальные особенности. Есть прецеденты, например - Япония. Один мой приятель, побывавший там, недавно рассказывал, что у них с Internet ситуация, конечно, лучше, чем у нас, но вообще положение аховое по сравнению, например, с Финляндией. То есть что получается: e-mail у людей есть, а с on-line гораздо сложнее. Объясняется все очень просто: Финляндия - это "проходной двор" для коммуникаций, а японцы - замкнутая культура, "сами в себе", плюс своеобразная структура языка... Так что трудно сказать, насколько Япония отстала от Америки и отстала ли вообще... Важны местные особенности.
Наверное, и россиян следует скорее отнести к замкнутым сообществам со всеми вытекающими последствиями и особенностями менталитета? Пожалуй, да.
Возникает еще один важный вопрос - как нам оценить перспективы? Если бы концепция "отставания от Америки" работала, мы могли бы уже сейчас точно предсказать, что будет в России через три года или через пять лет. Это был бы уже прогноз. Как быть, если мы отказываемся от этой концепции в связи с национальными особенностями? Нет, прогнозы давать можно, особенно по некоторым направлениям. То, что в дальнейшем количество пользователей, работающих исключительно с электронной почтой, будет неуклонно уменьшаться, - это факт. И то, что число пользователей on-line будет неуклонно расти, - тоже факт. Трудно оценить лишь сроки.
Спрогнозировать дальнейшее развитие Сети - задача чрезвычайно важная, особенно для бизнеса. Можно ли, скажем, оценить скорость перехода населения от UUCP к онлайновым режимам работы? Думаю, что прежде всего дело в пользователях. Есть так называемый минимальный уровень. Что это значит? Для того чтобы ходила почта, годится и 286-й компьютер. Реальных средств, которые бы обеспечили работу по TCP/IP для 286-х компьютеров, нет. И такие пользователи прекрасно обходятся почтой, больше им обычно и не надо. Вопрос в том, сколько времени в день человек решает затратить на свою связь с миром и на обучение тому, как этим пользоваться. Когда стоимость онлайнового доступа приблизиться к стоимости электронной почты и пользование онлайном не будет требовать каких-то специальных знаний, то есть станет common knowledge, тогда можно будет говорить о каком-то замещении. Пока разница по деньгам и по требуемым навыкам остается слишком высокой, ситуация не изменится.
Но существуют ведь средства TCP/IP для DOS, например Waterloo TCP. Или все-таки основная проблема в сложности настройки и работы? И в этом тоже. Как только пользователь начинает понимать, что такое TCP, ему UUCP уже не требуется. Хотя UUCP можно использовать через Waterloo, есть масса других более современных и удобных в работе средств. А просто UUPC хороша тем, что ею может пользоваться даже домохозяйка, я сам видел.
Насколько я знаю, вы не пользуетесь продуктами Microsoft? Пользуюсь, но они доставляют мне дополнительные хлопоты. На домашнем компьютере у меня стоит FreeBSD и Windows 95. Windows 95 - для людей, с которыми приходится обмениваться информацией. У них в основном стоят либо DOS либо Windows, при этом мне приходится заботиться о совместимости форматов файлов. Еще иногда в игрушки играю...
А чем "лазаете по Internet?" Под управлением FreeBSD у меня работает Netscape, и есть текстовый броузер Lynx. А поскольку я параллельно занимаюсь русификацией, то под Windows 95 у меня целый зверинец броузеров.
Правда, что их написано около сорока штук? Ну нет, сорок у меня не наберется. Есть несколько основных, которые имеет смысл использовать. К сожалению, разработчики большинства броузеров отстают по сервисным возможностям от Netscape Navigator и Microsoft Internet Explorer, которые выглядят круче. С другой стороны, с каждой новой версией ведущих броузеров возникают какие-то проблемы. То Netscape придумал JavaScript, то Microsoft - ActiveX...
И на эти технологии тут же переходят все Web-серверы... Да, этим, собственно, и определяются лидеры в гонке броузеров. И еще количеством денег, получаемых с продаж продукта. Вот в Netscape, кстати, не так много людей работает по сравнению с тем же Microsoft. А проблемами интернационализации продукта занимаются всего пять человек, среди которых в основном люди с Востока- китайцы, японцы.
Этим вызвано наличие кодировок Japanese, Chinese и Korean? Да, да, это было написано первым делом. Для них ведь это родное. Я пытался контактировать с Netscape, и на каком-то этапе это было даже удачно- они стали отвечать на письма, но потом ушли в совершенно глухую защиту.
Странно. В Netscape есть конкретный человек, отвечающий за интернационализацию. Но я не знаю, что с ним происходит... У меня есть адреса трех человек из пяти тех, кто занимается интернационализацией Netscape, но толку от этого никакого.
Андрей, вы знаете, что на выставке Netcom присутствовали представители Netscape и заключили соглашение с компанией Great Silicon Way о распространении своих продуктов в России? Я достаточно далек от официальных мероприятий и от компьютерных тусовок и поэтому не знаю, что происходит на рынке. Круг моего общения - в основном разработчики и комитеты по стандартам. Я знаю, что программисты, берущиеся за русификацию программного обеспечения, часто попадают в ловушку. Видит человек продукт, который не работает, и начинается... Как говорил Федор Михайлович Достоевский об особенности русских людей: "Дайте русскому школьнику карту звездного неба, которую он увидел в первый раз, и он через пять минут вернет ее исправленной". Но самое страшное в том, что программист начинает русификацию, не удосужившись хотя бы заглянуть в стандарты и прочитать, что там написано на этот счет. В результате получается: "Что-то здесь не работает. Мы сейчас подправим, и все получится".
Каково ваше отношение к "вавилонскому столпотворению" в кодировках кириллицы. То есть к тому факту, что существуют кодировки для русского языка в DOS, в Windows, для Unix и для Макинтоша? Нет никакого столпотворения. Существует такое понятие, как кодировка, принятая в операционной системе, которая сложилась исторически. И не надо это трогать. Если в DOS или Windows сложился определенный стандарт, пусть он живет и процветает. Речь идет о другом - о сетевой кодировке. Сетевая кодировка должна быть одна, для удобства. Она должна конвертироваться в локальную кодировку пользователя на входе и наоборот на выходе. Необходимо просто сделать таблицы перекодировки во всех нужных местах. Никто никого не хочет вытеснять, и пусть каждый работает с тем, что ему удобнее. Локальные кодировки невозможно привести к единому знаменателю - так никогда не будет. Нельзя, чтобы продолжалась ситуация, сложившаяся в Сети, когда на домашних страницах у всех написано одно и то же - "выберите вашу кодировку".
Говорят, что эта надпись - классический русский камень на распутье. Да, и это совершенно ненормальная ситуация.
Существуют ли какие-нибудь универсальные решения? Универсальных решений нет. Существует решение, например, для Windows 3.11 или для Windows 95. Каждое приложение должно поддерживать специальные таблицы для перекодировки из сетевой в локальную и наоборот. Так сделано, например, в Microsoft Internet Explorer. И хорошо бы, чтобы так поступали все разработчики программ. Но поскольку большинство остальных программ ничего "не знает" про наличие разнообразных кодировок, то оказывается гораздо проще поставить KOI-8 в качестве дополнительной кодировки Windows. Для Windows это практически решенный вопрос - есть раскладки клавиатуры и есть шрифты. Единственная проблема с KOI8-R - не каждому юзеру под силу все это хозяйство установить, и хорошо бы это было сделать на этапе подготовки операционной системы к продаже.
Большое достоинство системы Microsoft Internet mail-news в ее умении работать с KOI-8. Я думаю, что мои попытки повлиять на них тоже могли сыграть здесь свою роль.
А Netscape? В Netscape все получилось менее удачно. Чтобы работать в Netscape с KOI8-R, нужно ставить KOI8-шрифты. Кроме того, Netscape не умеет перекодировать сообщения. Они пытались реализовать перекодировку "сетевая-локальная", но не смогли это сделать во всех нужных местах и оставили свои попытки.
Андрей, какой операционной системой вы пользуетесь в повседневной работе? FreeBSD.
Почему не ее коммерческим вариантом - BSDI? BSDI уже давно устарела и к тому же продается за деньги.
Я вижу на столе компакт-диск со свежей версией FreeBSD... Это версия для разработчиков, snapshot, и я с ней работаю. При желании на диски этой серии можно подписаться по адресу info@cdrom.com.
Вы работали координатором проекта FreeBSD? Я - так называемый core team member, то есть член основной команды. Там демократии нет, там есть некая олигархия, команда, которая и принимает решения по поводу того, что войдет в следующие версии FreeBSD, а что - нет, и ведет весь проект в целом. Дело в том, что есть много вариантов усовершенствований, улучшений и исправлений, но не все они совпадают с принятой стратегией развития FreeBSD, а иногда даже противоречат друг другу. Развитие Unix-системы не должно нарушать принятых стандартов, в частности POSIX.
Вы до сих пор участвуете в проекте FreeBSD? Да, и причем достаточно активно. Я начал заниматься проектом с самого начала и до сих пор трачу на него большую часть своего времени.
Как это начиналось? Поставив на компьютер BSDI, я обнаружил какую-то плюху, сразу исправил ее и послал разработчикам. На что получил от них суровый ответ примерно такого содержания: "откуда у вас, в России, наша система, ведь мы ее туда не поставляем?"; далее в том же духе и ничего по существу вопроса. Я на них обиделся и поставил себе 386BSD (предшественника FreeBSD). Послав bug-report уже в команду 386BSD, я встретил благосклонную поддержку и участие и постепенно в это дело втянулся.
Существует, наверно, целая методология внесения исправлений в большой программный продукт? Единственный нормальный способ усовершенствовать большую систему состоит в том, чтобы правки вносились лишь в том месте, где система разрабатывается. Русификация FreeBSD стабильна именно потому, что делается на этом уровне.
Ваша работа? Да, в основном я ее и делал.
Кстати, FreeBSD часто ругают, сравнивая с Linux и приводя в пример дружественность поддержки. Говорят: "Вы посмотрите, сколько пользователей вам ответят, стоит только обратиться в телеконференции comp.os.linux.*" Дело в том, что все обсуждение, касающееся FreeBSD, давно уже ушло из телеконференций и перенесено в списки рассылки. Люди решили, что в засорённом эфире работать не стоит. На сервере www.freebsd.org все списки подробно перечислены. Недавно я сделал в Москве локальную зеркальную копию WWW-сервера FreeBSD для ускорения доступа.
Значит ли это, что все телеконференции USENET постепенно дрейфуют к спискам рассылки? Я вам не отвечу за весь USENET. Например, иерархия alt.sex.* явно не собирается стать списком рассылки, поскольку такой материал нужен всем. Но разного рода проекты и разработки пользуются исключительно списками рассылки - так удобнее и исследователям, и самим пользователям.
Вы читаете USENET? На заре появления USENET в России я действительно его активно читал или хотя бы просматривал. Теперь же мои интересы полностью удовлетворяются частными письмами или списками рассылки. Конференции вроде relcom.talk или relcom.netnews читаю очень редко, если уж совсем нечего делать.
Судя по размерам вашего компьютера вы не сторонник миниатюрных вещей. Или я ошибаюсь? Хорошей машины должно быть много.
Пентиум? Да нет, не люблю я Пентиум. Процессор у меня AMD DX4-133 за тридцать долларов. И его в принципе на все хватает.
Кто ваш провайдер? Я попеременно звоню и в Релком, и в Демос. Других московских провайдеров я не пробовал, да и незачем было. Из Питерских доменов мне хорошо знаком, например, pu.ru (Петербургский университет) - я там недавно хакера ловил.
Вы занимаетесь и такой работой? Да, security тоже приходится заниматься.
Значит ли это, что к вам можно обращаться за помощью в тех случаях, когда кому-то сильно докучают, например, атакуют банковскую сеть? Я не "полиция нравов", а, скорее, частный консультант. То есть ко мне можно обратиться за советом. Я знаю решения, применяемые в мире для защиты сетей, знаю, какое оборудование и программное обеспечение для этого используется в организациях. Но я не в состоянии физически отлавливать нарушителей.
Этим, скорее, занимаются службы безопасности или бандиты. А как насчет вашего оперативного вмешательства? Можно сделать мониторинг для отлова источников хакерских запросов и, обнаружив, сообщить: "Высылайте бригаду". Но главным всегда остается профилактика. Основное в компьютерной безопасности, чем я собственно и занимаюсь, - это сбор информации об обнаруженных в системе "дырках" и их своевременное "залатывание". Есть внутренняя тусовка, и как только человек из нее заметил "дырку", он информирует остальных людей, завязанных на проекте, пока сведения не успели расползтись по миру. Вот этим я персонально и занимаюсь. Недавно хакер из СПбГУ проник на freefall.freebsd.org, пользуясь паролем моего знакомого, вот мы его и вычисляли.
Вычислили? Да. Я связался с администратором и попросил принять меры. Администратор ответил, что этого нехорошего юзера отключили.
Наверное, так удачно заканчиваются не все истории? Особенно если хакер - студент, работающий из образовательного учреждения. Университеты - это рассадники хакерства и хулиганства. Помню, к хакерам в университете относились так: если его ловили, то выгоняли, а если было не поймать, то тогда ему предлагали работу в вычислительном центре, где в ту пору еще стояли БЭСМ-6. Собственно, со мной так и произошло. Ведь если хакера не застали на месте преступления, то доказать ничего нельзя. Кроме того, охотник за хакерами в терминальном классе четко выделяется своим бегающим взглядом.
То есть ловля происходит на физическом уровне. Не увидев хакера за работой, уличить его невозможно? Ведь он скажет: "Не было меня там тогда, ничего не знаю..."
А если установлено, что реквизиты, использованные для входа в сеть, принадлежат ему? Ну и что? Он скажет: "Мой пароль украли, а меня подставили". Так что проблема ловли сложнее, чем кажется на первый взгляд.
Как можно бороться с хакерами? Я уже говорил - это сложная проблема. Можно отключить данный вход в сеть, но ничто не помешает ему подключиться у другого провайдера или даже у того же, но под другим именем. У нас нет никакой законодательной базы на этот счет, и я считаю, что это правильно. Системы в первую очередь должны быть защищены программно, а не законодательно. Это - единственная надежда, что слабые места будут исправляться. А если хакерство будет уголовно наказуемо, то "дырки" в программном обеспечении так и останутся, и исправлять их будет совершенно никому не нужно. Сейчас хакеры практически безнаказанны, и это гарантия того, что инженеры будут внимательно относиться к безопасности разрабатываемых продуктов. Я считаю, что хакеры - санитары Сети.
Раз мы подняли вопрос о безопасности компьютерных сетей, нельзя не затронуть еще одну тему - секретность передаваемых данных. Как, по вашему, обстоят дела с ведением закрытой деловой переписки или, скажем, коммерции в Internet? Секретность передаваемых по Сети данных действительно является одной из важнейших проблем. И основная причина в том, что протоколы Internet из-за особенностей внутренней структуры не обеспечивают требуемый уровень секретности. Из заслуживающих внимания программных средств защиты можно назвать IPSec, SSL от Netscape и SKIP от Sun. В защиту данных вкладываются очень большие деньги, и над этим работают действительно компетентные люди, но до сих пор не выработаны решения, которые бы устанавливались легко. К сожалению, российские программисты вряд ли смогут предложить здесь что-либо интересное. Это направление движется, и я думаю, что через несколько лет появится что-то приемлемое.
Существуют правительственные ограничения на экспорт алгоритмов шифрования за пределы США. У Internet Architecture Board (IAB) и Internet Engineering Steering Group (IESG) есть четкая позиция на этот счет, с которой я согласен: экспорт, а стало быть, и свободное распространение алгоритмов шифрования ограничивать нельзя ни в коем случае хотя бы потому, что эта политика ослабляет и дискредитирует саму систему шифрования. Разработчики - против правительственного контроля над этими технологиями.
В экспортных ограничениях заинтересован крупный бизнес? Ничего подобного. Тут интересы крупного бизнеса совпадают с мнением разработчиков. Этому крупному бизнесу как раз и стало бы легче жить, появись надежные способы криптозащиты на международном уровне.
Вы делали локализацию системы шифрования почты PGP (Pretty Good Privacy). Вы специалист в области криптозащиты? В комментариях к PGP Циммермана есть очень интересный рассказ о том, что он, будучи студентом, изобрел, на его взгляд, "непробиваемый" алгоритм шифрования, который использовал везде. А когда он подрос, то выяснил, что этот алгоритм элементарно раскрывается. Я имею в виду, что заниматься шифрованием в сетях TCP/IP могут только специалисты очень высокого класса как в криптографии, так и в алгоритмах TCP/IP, а таких людей можно просто пересчитать по пальцам. Поэтому многие средства, предлагаемые на рынке сейчас, можно назвать "змеиным маслом", то есть так называемым "лекарством от всех болезней" со всеми вытекающими последствиями.
Но с шифрацией почты-то проблема решена? Ну разве что при помощи PGP. Считается, что ее пока никто не вскрыл, то есть факты взлома неизвестны.
Разве взломщик признается во взломе? Легче признаться и заработать на этом мировую известность, чем пробовать получить какую-то личную выгоду из сломанной защиты, что отнюдь не безопасно для жизни, если связано, например, с большими деньгами. Примеров признаний немало, и о фактах взлома обычно сразу сообщают.
В чем, кроме локализации, выражалось ваше участие в проекте PGP? Я "крутил" ее на разных кодировках, из внутренней во внешние и наоборот, с криптографией это не было связано. Я не специалист по криптографии, то есть некоторые обзоры на данную тему я понимаю, но делать что-то в этом направлении я не берусь.
У вас на стене висит диплом, полученный за "Russian programs for Internet contest" ("конкурс русских программ для Internet"). Что это был за конкурс? Я называю этот диплом "подтверждением статуса в социуме". Он был выдан кем-то из "Телепорт-ТП" в этом году. По телеконференциям прошло сообщение о конкурсе, и я на него среагировал - послал письмо с предложением зайти на мою страничку по русификации http://koi8.pp.ru/ и посмотреть. Они посмотрели, и им понравилось. А я получил диплом и пятьсот долларов, с вычетом налогов.
Ссылки на страницы вашего сервера, посвященные русификации программных продуктов, поставлены на очень многих российских Web-серверах, а это огромная работа. Она кем-то спонсируется? Раньше она никем не спонсировалась, а теперь спонсируется Релкомом, и на моих страницах есть его логотип. Если кто-то еще захочет стать моим спонсором - милости прошу, на моих страницах появится и его логотип.
У сервера nagual довольно высокая посещаемость. Нет предложений от других людей размещать на нем ссылки? На сервере стоит счетчик. Насколько я помню, на страничке про KOI8-R сейчас зарегистрировано что-то около 87000 посещений с ноября 1995.
Внушительно по нашим меркам. Да, но предложение ставить рекламные ссылки пока поступило только одно. Предлагалось делать зеркальные серверы. Ссылки на два из них, оказавшиеся работоспособными, я поместил на мою страничку.
В мире почтовых программ существуют несколько устоявшихся версий UUCP, и большинство российских пользователей DOS шлют и принимают почту при помощи UUPC/@, продукта, разработанного вами. Есть несколько специфических для России проблем, например качество телефонных линий. Коммуникационные программы должны быть надежны и легко восстанавливаться после потери связи. На Западе плохо понимают, что такое несколько телефонных номеров у провайдера. UUPC/Extended пришлось доводить до нужного уровня, так появилась UUPC/@.
Что значит "@"? "Собачка" значит "от ache", то есть от меня, чтобы отличать от оригинала - UUPC/Extended. Я переписал первоначальную версию программы, оставив все имевшиеся копирайты и выполнив условия лицензии.
UUPC/@ было временным решением? Появление UUPC/@ подтверждает тезис о том, что временное - это самое постоянное. Тогда еще ни у кого не было и мысли о том, что UUPC придется сопровождать и делать дальше. Ну а сейчас я - координатор проекта, то есть не пишу активно, а вношу правки, принимаю и рассматриваю предложения и выпускаю "централизованные" версии. Последняя версия UUPC/@ на сегодняшний день - 6.19. Пишется все на старом добром компиляторе Borland 3.1.
Некоторые провайдеры до сих пор предлагают версию 5.09. Это дело провайдеров, какую из версий считать наиболее стабильной. В каждой версии есть ошибки. В следующей версии они исправляются и вносятся новые. И с каждой версией появляются дополнительные возможности.
Чья была идея встроить "попугайские буквочки", ползущие по экрану во время работы UUPC? Помню, что не моя. А заключалась она в том, чтоб "было видно, что происходит". UUPC/Extended ничего не писала на экран во время работы. А так стало видно абсолютно все.
Каковы ваши планы по развитию UUPC? Планы вот какие: если мне пришлют хороший код, я его вставлю. Или четко описанную и воспроизводимую ошибку попробую исправить.То есть, я продолжаю заниматься координацией, но не разработкой. Если кому-то интересно сделать с UUPC/@ что-либо конкретное, пусть присылает свои материалы.
Андрей, ваш сервер написан в основном по-английски. С чем это связано? Вам, наверное, часто предлагают работу за границей? Причина проста - коль скоро материалы посвящены русификации, то нет смысла писать по-русски. Ведь обращаются те, у кого этого русского-то и нет. Что касается работы за границей, то у меня достаточно много было предложений навсегда поехать работать в штаты, но меня это совершенно не устраивает, я не представляю, что буду делать в чужой стране без любимого культурного бэкграунда. Я поездил на различные конференции - чувствуешь себя в какой-то изоляции... Ходишь, а перед тобой как за стеклом аквариума двигаются люди, что-то происходит... На предложения я обычно отвечаю так: "давайте я на вас буду работать здесь", а их этот вариант не устраивает - меня в этом случае невозможно контролировать. Слишком непредсказуема для западного бизнеса страна, в которой я живу.
Западные бизнесмены нередко покупают рабочую силу здесь, в России, платя не очень большие по их меркам деньги. Так в этом и дело - они эти деньги просто выбрасывают и не рассчитывают на серьезную отдачу. А если вдруг получают что-то взамен, то рассматривают это в качестве подарка.
Андрей, как вы относитесь к бизнесу и предпринимателям? Сам я скорее - программист-исследователь. Но я уважаю профессиональное умение людей безотносительно к тому, чем они занимаются. Вот предприниматели умеют делать бизнес хорошо, а я, так сказать, заточен под другое дело.
Приходилось ли работать над коммерческими проектами? Да, конечно. При этом я или делаю все целиком один, или стараюсь выделить свой локальный кусок и делать его самостоятельно. А вот быть администратором в смысле налаживания контактов между людьми мне не очень хорошо удается. Администраторство в софтверном бизнесе, как и в любом другом, - это особый талант, причем для обладания им необязательно даже быть программистом.
Андрей, мне известно о вашем большом интересе к стилю живописи под названием Anime. Коллекция этих картинок собрана на сервере. Кроме того что мне нравится Anime, мне хотелось протестировать http-демон, на котором работает Web-сервер, при настоящей нагрузке. И картинки сделали это возможным. Что касается самого понятия Anime, то произошло вот что. У японцев был собственный живописный стиль, семантически похожий на русский лубок. Это нельзя назвать комиксами, скорее серией картинок с текстами. Потом в связи с влиянием американцев произошло смешение стилей - на стыке американских и японских комиксов вырос некий жанр, в котором действуют самобытные и трогательные персонажи. Постепенно из комиксов это перешло в мультики. Сейчас по телевизору идет сериал "Sailor Moon" - это пример стиля Anime. Первоначально сам жанр Anime не предполагал откровенной эротики, там действовали герои детских мультфильмов или комиксов. Потом кому-то пришло в голову скрестить две казалось бы несовместимые вещи - эти выразительные, берущие за душу огромные глаза и грубую порнографию.
Получился "изысканный букет"? Да, и как раз такое сочетание мне очень нравится, смешение противоположных вещей. Кстати, эта разновидность стиля Anime называется Hentai, по-японски это "перверт, извращенный". Что происходит с обыкновенным порно: почему-то девушки, снимающиеся в нем, обладают, мягко говоря, странным выражением лица. То есть лица либо как-то стерты, глупы, либо на них застыла совершенно неестественная маска, призванная создавать видимость страсти для не очень привередливого зрителя. Что-то неладное с душой. Чего-то не хватает. А органичность, живость, очарование свойственны лишь персонажам Anime.
Откуда берутся картинки Anime? Большинство картинок - это копии с экранов компьютерных игрушек. Некоторые рисуют непосредственно, но в основном это игрушки с выбором сюжета и переходом от одной картинки к другой. Эти игрушки в Японии пользуются большой популярностью и являются заметным элементом компьютерной культуры. Вообще, у этой нации потрясающее чувство вкуса. Недавно я приобрел полнометражный мультфильм в стиле Hentai Anime, "La Blue Girl", "голубая девочка", и с удовольствием его посмотрел. Там есть и потрясающе точная пластика движений, и элементы тантрической магии.
Андрей, на вашем сервере находится масса ссылок на оккультные и магические источники в Интернете. Расскажите об этом увлечении. Ссылки на моей страничке для меня сейчас вполне актуальны, а вот астрал в понимании западной оккультной традиции теперь мало интересен, я этот этап уже прошел в своей жизни.
Именно поэтому я не увидел на стенах вашей квартиры никаких жабьих лапок или высушенных змеиных кожиц? Да нет, у меня есть некоторое количество фенечек, и вовсе необязательно, чтобы магические атрибуты висели на стенах. Они могут храниться и в ящике шкафа. Вот, например, карты Таро, которыми я иногда пользуюсь, есть масса интереснейшей литературы. Но это - тема для отдельной беседы... Беседу с Андреем Черновым вел Илья Усов - ведущий редактор журнала "Мир Internet" "Мир Internet" N3 1996 год
submitted by Ache666 to u/Ache666 [link] [comments]

Урок 21. Добавление Activity - cоздание многоэкранных приложений  Android Studio Как создать исполняемый jar файл в IntelliJ IDEA Урок 1. Мобильное приложение за 20 минут. Программирование на Java: создание игры Змейка. Часть 1. Разработка Android приложений. Урок 1 - Вступление.

В поле "Версия Java EE" выберите Java EE 5. Для веб-проектов Java EE 6 и Java EE 7 использование дескриптора развертывания web.xml не требуется. Проверьте, как работает приложение на вашем мобильном устройстве. На планшете программа должна отображать список публикаций в блоге в формате заголовка и анонса. Есть jar-архив с приложением java. Нужно сделать так, чтоб пользователь мог запускать приложение не из командной строки, а просто кликнул по ярлыку и всё запустилось (под винду). Как это сделать? Многие привыкли писать на Java десктопные и мобильные приложения. Но что насчёт веб-приложений? Сегодня мы расскажем, как создать такое средствами Java, Servlet API и JSP без каких-либо сложных фреймворков. Установка среды для Java: JDK и JRE Если у вас еще не установлены Java Development Kit (JDK) и Java Runtime Environment (JRE), то их необходимо установить. Сделать это можно на сайте Oracle. Скачайте и установите JDK и JRE.

[index] [651073] [2427694] [4177779] [75232] [92392] [4027019] [1814846] [1306759] [1226135] [3170075]

Урок 21. Добавление Activity - cоздание многоэкранных приложений Android Studio

Когда умрет Java, стоит ли ее выбирать как свой путь развития - Duration: 11:23. Sergey Nemchinskiy 115,972 views 11:23 Как сделать запускаемый Java-файл или Java ... делаем простое веб приложение на Java ... на java: как открыть jar ... Как создать приложение для начинающих? Пошаговый видео-урок, как создать приложение для начинающих? - Duration ... Очередной урок, как создать мобильное приложение за 20 минут. На этот раз создаём приложение qr код. Это ... Посмотрев урок вы сможете установить и настроить джентльменский набор Android разработчика, а именно JDK(Java ...

#