• Как удобнее хранить пароли для веб-студии?

    Думаю, чтобы не было проблем с синхронизацией, нужна единая БД для всех с поддержкой транзакций. В таком случае подходят веб-решения, где пароль шифруется в браузере и отправляется на сервер. Мне всегда некомфортно, что такой сервис может исчезнуть вместе с паролями, хотя сама концепция нравится. Например, LastPass дает решение всех этих проблем.

    И что касается доступа к паролю для разных групп пользователей: тут есть сложность, поэтому "маленькие" менеджеры типа KeePass это не умеют (и вряд ли будут). Подавляющее большинство из них работает на ассиметричном алгоритме - база шифруется мастер-паролем. Если нужно дать доступ к части другому пользователю, он должен знать этот мастер-пароль и никак иначе. В таком случае напрашивается вывод: держать общую базу данных с общим мастер-ключом, но оно неудобно + нельзя без проблем отсоединить одну сторону от доступа к паролям. Поэтому нужен механизм генерации общего ключа, который бы (ключ) был известен только лицам, участвующим в обмене, и система управления, которая бы могла регенерировать эти ключи, автоматически создавать общие БД и т.п. => нужен централизованный сервис, а поэтому проще всего использовать веб. LastPass, например, имеет систему общих папок и генерации общих ключей для них.

    А еще лучше не иметь общих паролей, чтобы везде были индивидуальные аккаунты, конечно :)
  • Что происходит когда вызываешь Object.apply(this ) в конструкторе "класса"?

    Евгений Петров: так ведь не надо эту конструкцию использовать для наследования. Она просто вместо new.
  • Что происходит когда вызываешь Object.apply(this ) в конструкторе "класса"?

    Евгений Петров: тогда тоже немного поясню. Такое поведение я описал в своем ответе (https://toster.ru/answer?answer_id=570797), но убрал оттуда Object.create. Потому как если его там оставить, он будет копировать объект prototype у конструктора, а мы-то ведь используем это всего лишь для того, чтобы при создании экземпляра передать аргументы в виде массива, в итоге у нас будет лишняя копия прототипа, которая никуда не денется: на нее есть ссылка из функции-конструктора. Если же попробовать оставить это там, то тогда данную конструкцию можно переписать для наследования, но это совсем другая история (по сути, вызывать еще конструктор для нового класса с apply и уже можно использовать).
  • Что происходит когда вызываешь Object.apply(this ) в конструкторе "класса"?

    Евгений Петров: да, если следовать именно примеру, то там мало масляное. Я просто воспринял это в своем контексте: где-то видел такую "фичу" для использования apply при инициализации объекта, а поэтому "Object" для меня стал любым объектом.
  • Что происходит когда вызываешь Object.apply(this ) в конструкторе "класса"?

    Касательно
    AnyClass.prototype = Object.create(Object.prototype);
    : оно создает новый объект. В итоге таким образом мы имитируем реальное ООП, когда у нас разные прототипы для разных "классов". Раньше для этого нужно было писать костыль с пустым конструктором, чтобы создать объект, а сейчас вот так удобно. https://developer.mozilla.org/ru/docs/Web/JavaScri...
  • Практическое применение f((yield x))?

    К предыдущему оратору присоединяюсь :)
  • В чем преимущества Ubuntu LTS(Long Time Support)?

    Adamos: это у вас редкая конфигурация на работе, я о таком опыте только пару раз читал, но не видел и даже не слышал от знакомых админов. Если на работе, то поголовно винда. Контроллер домена на Samba 4 - это еще возможно, но чтобы все... Рад за вас, если все так. :)
  • Как сделать редирект старых ссылок на новые?

    Сергей Шилов: этот вариант работает у меня на localhost apache, откуда я его и достал, собственно. Не работать может из-за того, что mod_rewrite не подключен. Или AllowOverride выставлен в None. Оба параметра в конфиге, настраиваться может через панель шаред-хостинга.
  • Правильно ли составлена команда WGet?

    Виталий Пухов: да, это похоже на то, что нужно, но я не использовал remote, возможны ui-косяки, свойственные подобным проектам, тем более, судя по sourceforge, оно не обновлялось с 2013 года. Кроме того, я еще нагуглил webui - https://github.com/ziahamza/webui-aria2, не знаю, насколько она мощна, но новее. Причем не требуется разворачивать веб-сервер для нее. Посмотрите еще uGet.

    А теперь по части, где были задеты мои глубокие чувства))) Скрипт - это не костыли. И "нормальный" язык - это не только C#. Python не менее нормальный язык, например. Ну и куча проблем возникает потому, что нет нормального прочтения мануала, нет понимания, как работает Linux вообще, как я подозреваю. Я бы сделал скрипт, и он бы у меня работал годами, не поверите. У меня на серверах есть скрипты, делающие бэкапы БД, например - годами работают, по своей сложности они примерно равны тому, что нужно в этом вопросе, может, чуть попроще. С таким подходом будут на чем угодно костыли.
  • Как организовать перелинковку страниц?

    Отправьте эту картину на ebay, яндекс.маркет, тысячи каталогов, а еще на каждый сайт, где шапка появляется на каждой странице и, соответственно, на нижний уровень не просто ссылаются, а повсеместно ссылаются. "Вот пример схемы" - это не аргумент. Ее вам Гугл прислал?

    Я верю в реальные примеры и информацию от самих поисковых систем, либо родившуюся в обсуждениях на специальных ресурсах, где появляется авторитетный человек, посты которого или место работы я могу посмотреть.

    Структура сайта должна быть логичной и ссылки соответственно, не более того.
  • Правильно ли составлена команда WGet?

    А что понимается под "отдельными папками"? То есть нужно сохранить структуру директорий как на сайте? Или самих файлов с URL для загрузки много, и они лежат в разных директориях, и надо в эти директории скачать файлы соответственно?

    Что касается многопотоковой загрузки - это умеет aria2 (https://ru.wikipedia.org/wiki/Aria2), она тоже консольная.

    p.s. В любом случае придется писать скрипт, будь то на bash или, например, на python, и он справится со всеми задачами. Дополнительно можно оттюнить tc для приоретизации трафика. В общем, есть, куда разогнаться)) Одной командой тут не обойтись.
  • Правильно ли составлена команда WGet?

    Как это не может параллельно? У нас же bash-сила доступна - есть &, нужно просто скрипт написать.
  • Практическое применение f((yield x))?

    Хочется еще добавить, что это всего лишь двойной yield, а None влетает в функцию потому, что в списковом выражении генератору не передается аргумент (это делается через send, и такое поведение уже называется сопрограммой).

    А yield можно делать хоть тройной, хоть еще какой.
    def f(x):
        return u',\n {}.\n'.format(x.lower())
    
    print(u''.join(f((yield i) or (yield u', {}, ууу'.format(i.lower())) or i) for i in [
        u'Ветер с моря дул',
        u'Нагонял беду',
        u'И сказал ты мне',
        u'Больше не приду'
    ]))
  • Какие приемы для именования переменных в css препроцессорах используете Вы?

    Вячеслав Лебедев: еще сильно зависит от задач, что конкретно верстаете. Но независимо от архитектуры, думаю, существует пара истин: если переменная уникальна, то просто дать ей то же имя, а если не уникальна, то дать префикс, который отразит, к какой части дизайна она отнесется. И, думаю, не важно, что использовать, хоть лапшовый CSS, хоть БЭМ, хоть костыли, с таким подходом все будет поддерживаемое :)
  • Какие ЯП не требуют кучу прикладнухи для устройства на работу?

    Cyrax2014: да, если коротко, то по этому признаку.

    Если говорить про веб-разработку, то я бы в первую очередь сделал акцент на фронтенд: js/css/html и сопутствующие технологии. Потому что веб-разработка без этого не бывает и фронтенд становится все более тяжелым и сложным, тем более, что работа в этом направлении есть что в офисе, что на фрилансе. Кроме того, можно даже попробовать уйти в мобильную разработку со стеком веб-технологий с помощью, например, titanium sdk (https://www.clevercards.com/ - у них мобильные приложения как раз сделаны с titanium sdk и судя по отзывом моего друга, который там работает, все неплохо, а он, что называется, full stack web developer). Что касается бэкенда, то там js тоже может пригодиться, ведь есть node.js. Что касается иных технологий, я бы их разделил на скриптовые и нескриптовые. Скриптовые: php, python, ruby. Я бы выбрал python (сам на нем сейчас пишу, кстати), это язык общего назначения, можно кодить все, что нетребовательно в скорости, кроме того писать демоны, прикладное ПО (биллинг), скрипты какие-нибудь. На фрилансе заказчикам глубоко фиолетово, на чем их сайт внутри. Python минималистичен, мощен, имеет жирное коммьюнити, хороший фреймворк, который развивается - Django. PHP в плане дизайна языка ему проигрывает со свистом и похож на эволюционный выкидыш. Ruby очень модный, но моложе и его можно увидеть почти только в вебе, там хуже доки и меньше коммьюнити. Во многом фреймворки вдохновляются именно рельсами, но я бы не стал туда идти, тем более, что как только вижу, как выглядит код на руби, так сразу фу - слишком много спец. символов. А по сути, это тот же питон, что по скорости, что по идеологии. Вакансий много на PHP, потому что он популярен исторически, значительно меньше на Python/Ruby, но если постараться, сможете найти. В любом случае питон - язык общего назначения, это важно. На нем и биллинг можно написать и скрипты связующие и обработку данных и тесты и все это красиво и изящно. Нескриптовые: C#/Java. По моему субъективному мнению, C# интереснее как язык (там есть linq, например), но ограничение под виндовые платформы. Мне всегда казалось, чтобы работы достаточно что на C#, что на Java, тут с этим проблем нет. Идеологически эти языки похожи, подходы похожи, оба развиваются, но в обоих случаях имеется дело со статической типизацией, тру ООП, это немного меняет мышление в целом в сравнении с js/python. Я за скриптовые технологии, т.к. они более динамичные и интересные, их надо двигать вперед, а не убегать от них. Но в любом случае я бы начал с фронтенда сейчас (хотя в свое время я начал наоборот - с бэкенда, потому что это был год 2005 и php/apache/cms, все дела), возможно, что вы и не уйдете даже в бекенд или не сразу/не скоро. В целом можете выбирать любую технологию из написанных, не пропадете. Сильно зависит также от ОС, которую используете. Я, например, Linux использую много лет, в итоге каким бы хорошим не был C#, он отваливается. В вебе довольно легко мигрировать с технологии в технологию, там как-то опыт в целом больше решает, код в целом, изящность решений, качество. Знание Linux и сетей для веба очень важно.

    Что касается мобильной разработки и если нет желания тащить туда веб за уши (что медленно и непопулярно поэтому), то нативные языки. Область развивается, перспективы есть. Я не разрабатывал под мобильные платформы, но по субъективным ощущениям у них много проблем с ресурсами, что может накладывает ограничения на применямые алгоритмы обработки данных; они часто имеют дело с API, написанными на веб-инструментах, и, в целом, многие приложения лежат очень близко к вебу. Я бы назвал эти области смежными.

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

    C/C++ используются в другой области: это могут быть сети, десктопные приложения, игры, обработка/визуализация данных. По моему субъективному мнению, вакансий достаточно. Входной порог выше, чем в веб/мобильную разработку. Не сказал бы, что сложнее, просто все инструменты менее попсовые и требуют больше знаний для обращения с ними. Это очень широкая область, я имею опыт разработки только на C по фану, поэтому не могу компетентно подробно рассказать. Мне C очень нравится как язык, он компактный и минималистичный, как будто это ассемблер на высоком уровне. Если хочется меньше заниматься интеграцией компонентов и больше реализацией алгоритмов, обитать на более низком уровне, то эта область будет ближе.

    Но, возвращаясь к моему изначальному посылу, нужно быть инженером. Обладая базой и понимаем в области алгоритмов, языков, ос, бд, архитектуре по, сетей и интересуясь математикой (например, алгеброй; я в последнее время начал понимать, что там много интересного и нужного, ее нужно знать/интересоваться, она поднимает общую культуру как минимум), вы можете быть специалистом в любой области, вы можете двигаться по смежным областям). Специализацию хотя бы в целом я бы выбрал по интересу, все остальные пути неправильные :)
  • Какие ЯП не требуют кучу прикладнухи для устройства на работу?

    Cyrax2014: я примерно так в жизни и делаю, только при этом не все рандомно пробую, а иду согласно интуиции. То есть ВНЕЗАПНО мигрировать в системное программирование так вот просто - ни за что. Но могу сидеть, что-то читать, увидеть код на асме, по фану попробовать подебажить, и тут понесется и мб завтра буду читать фундаментальную литературу. Кстати, с асмом так и было, пару приложений на нем писал (универского уровня), но не зацепило, но зато дало более глубокое понимание, например, стека вызовов, типов данных, рекурсии, теперь дебага не боюсь, хотя очень редко использую его.

    Я, например, таким образом забурился в сети. Около 8 лет назад поставил домой линуху, настроил там сеть, зацепило и понеслось. С тех пор так или иначе связан с сетями, даже немного в провайдере поработал.

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

    Так что в целом у меня идея "главное, чтобы интересно", а дальше уже разберемся. Это такой идеалистичный подход, не от общества, а от себя.

    Вот даже взять флэш, с него сейчас наблюдается миграция на html/css/js. Кто-то, допустим, начинал изучать флэш, было очень интересно. И сейчас эта технология оказалась бесперспективной, но если человек специализировался в вебе, то ему html/css/js либо уже знакомы, либо не так сложно туда войти. И вот, потенциально для него где-нибудь есть вакансия переписывать флеш-части, например.

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

    Оффтоп. Могу вам отвлеченный пример привести, с которым вы, скорее всего, вообще не связаны. Среди вокалистов есть люди, которые учатся петь изначально с хрипом. Это очень нужно в стилях блюз/рок/метал, там если ты не умеешь кричать, то ты не вокалист, грубо говоря. И вот эти люди начинают сразу с хриплых звуков, они используют совместно с голосом верхние ткани гортани (ложные связки) и начинают таким образом петь. Через какое-то время под хриплым звукоизвлечением, если делать все грамотно, развивается и чистый голос, т.к. он - это основа тембра. Причем из-за склонности пения в таких стилях высоко, развивается наисложнейшая часть диапазона. Я таких людей наблюдал и продолжаю наблюдать, например. А вы представляете, сколько людей думает, что все это бесперспективно, что все эти звуки кривые и никуда не годятся. Но главное - это интерес. Есть примеры, когда такие люди в будущем начинают петь чисто, потому что хотят разнообразия. Это на многих музыкальных группах можно проследить. Это называется подлинное развитие, когда человек в целом постигает все плавно и по интересу. А можно посредственно петь в театре и чтоб платили. )
  • Какие ЯП не требуют кучу прикладнухи для устройства на работу?

    Cyrax2014: ну почему не стоит, конечно же стоит! Это развитие: вы же не пилите себя под вакансию, а идете туда, где _интереснее_ и больше платят. Я, когда говорил, что "не стоит пилить себя под вакансию", имел в виду, когда неинтересно и хочется быстрее ради того, чтобы работать и платили. Вот, например, представим, что вы что-то знаете в информационной безопасности, но бумажная работа вас раздражает, но вы все равно туда идете, потому что хорошее место, например. Для меня этот вариант невозможен, я бы просто впал в депрессию от такой работы, и не спасло бы ничего. По образованию я как раз безопасник, и это не мое.

    А что касается "затратил время, но вакансий нет" - это обычно сразу понятно и обычно есть смежные области, которые тоже интересны и вакансии есть. Такому самое место оставаться в хобби и поддерживать вас как специалиста, в любом случае общий скилл выше будет.
  • Iptables и правильное перенаправление на 80 порт?

    Не совсем понял, что вы хотите сделать, и в чем сложность добавить multiport. Также не вижу, где ACCEPT на порт 3011, с текущими правилами не должно работать. По улучшению и оптимизации: не использовать ACCEPT для FORWARD, использовать собственные цепочки, чтобы не было длинной портянки правил. За одним и проще переписать будет правила в нужном порядке.
  • Полная ли жесть данный код на python?

    DmitryPhilimonov
    @DmitryPhilimonov Автор вопроса
    Андрей Дугин: здесь с вами согласен. В реальных проектах, конечно, лучше придерживаться общепринятого стиля, либо того, что принято в команде.
  • Полная ли жесть данный код на python?

    DmitryPhilimonov
    @DmitryPhilimonov Автор вопроса
    Андрей Дугин: насчет преимуществ и "тех же яиц, только сбоку": рекомендую обзорно почитать про лямбда-исчисление (не углубляться в формализм) и про функциональную парадигму в целом (на хабре были статьи в том числе), можно обзоры языков вроде хаскеля/ерланга. Подозреваю, что вы не работали в этом направлении. Мне этот подход интересен, и я иногда "балуюсь" в коде. На практике же есть 2 огромных плюса: проще тестировать, проще распараллелить такую программу. Ну и эстетическое удовольствие, когда вместо кучи рутины (переменные какие-то, циклы, все это много места занимает, а если язык статический типа джавы, это просто полный ад), можно быстро написать маленькую функцию и коротко решить задачу.