Задать вопрос
  • Стоит ли брать телевизор для работы?

    NeiroNx
    @NeiroNx
    Программист
    У телевизоров матрицы хуже, так как не предназначены для близкого использования. Брал, поставил обратно монитор. Думаю попробовать монитор 27 с 1920х1080, что тоже мало для 27.
    Ответ написан
    2 комментария
  • Как парсить "нечистый" JSON?

    Полностью покажите текст, судя по ошибке впечатление, что в response и двух байтов нет.
    Ответ написан
    7 комментариев
  • Правильно ли таким образом шифровать пароли?

    @MoonMaster
    Программист и этим все сказано
    Согласен с evnuh. Вы действительно не разбираетесь в хешировании и шифровании.

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

    Шифрование - это алгоритм двунаправленый. Существует различные алгоритм (с открытым, закрытым ключом и т.д.). Суть шифрование - выполнить преобразование над текстом с помощью ключа и расшифровать его может только пользователь для которого предназначено данное сообщение.
    Ответ написан
    Комментировать
  • Для чего нужен Docker?

    @viiy
    Linux сисадмин \ DevOps
    Представьте что нет никакой ложки докера.

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

    2) У вас есть физическая машина + на ней виртуалки. Вы выделяете под каждую задачу свою виртуалку, там сидят отдельные пользователи, вы навели какой то порядок. Появляется задача - пользователи хотят php 6, а его нет, хотят python3, а его нет, хотят Mongo, а она старой версии. Вы обновляете репозитарии, качаете новые пакеты, ставите, часть пользователей довольны, часть нет - им нужна старая версия какая была. Упс!

    3) Одна физическая машина + еще больше виртуальных машин. Вы разделили всех пользователей так, чтобы никто не дрался за версии софта, если нужен php6 - иди на эту машину, нужен php5 - вот на эту. Все счастливы, но появляются разработчики, которые говорят буквально так - "а у меня на рабочей машине все работает, я перенес все как было на виртуалку, а у меня появляется ошибка missing library libXXX.so.X". И вы понимаете что вам остается только создать полную копию машины разработчика, чтобы софт поехал на этой виртуалке без ошибок... И тут появляется Docker! :)

    4) Docker решает именно эту проблему. Вам не нужно заботится о софте который установлен на сервере/виртуалке. Вы просто берете и переносите софт со всеми "кишками" на другой сервер и он просто работает. Работает за счет того, что все "кишки" это слои файловой системы нанизанные как бисер друг на друга. Дополнительно решается проблема свободного места, т.к слои многократно переиспользуются контейнерами, если вам нужен php + одна библиотека, а другому php + другая библиотека, вы используете (грубо говоря) слой php, а для дополнительной библиотеки делаете отдельный слой, одновременно другой человек делает над php другой слой и вы не деретесь между собой и не видите чужих библиотек. Это грубо и скорее всего ради одной библиотеки никто новый слой не делает, делают слой пожирнее.

    Все запущенные процессы Docker помещает в изолированную среду процессов, файловой системы и сетевого стека. Есть много особенностей по работе с Docker, т.к он предполагает, что в одном контейнере вы запускаете один процесс. Если вам нужно запустить целый набор демоном, тут появляются проблемы, нужно писать шелл-скрипт, который все это поднимет в контейнере. Так же есть особенности по сети, файловой системе. Для кого то Docker спасение и решение всех проблем, но я как сисадмин от этого всего не в восторге.
    Ответ написан
    15 комментариев
  • В чем главное различие между Windows API, DirectX и OpenGL?

    Rou1997
    @Rou1997
    Вопрос должен звучать как:
    "В чем главное различие между GDI/GDI+, DirectX и OpenGL?"

    Windows API - это не только GDI и GDI+, но еще и GUI, файловая система сеть, короче, полноценное низкоуровневое (для XXI века) API ОСи, на котором так или иначе написаны все программы. И вроде это и из названия понятно, не?

    GDI/GDI+ изначально предназначены не для игр, а для отрисовки GUI, который в те старо-добрые времена не ассоциировался с такой кучей свистелок и перделок, как сейчас. Потому он и не заточен под сложную графику, и навороты GDI+ это потолок возможностей графики для GUI.

    у DirectX так же? Но почему она тогда не является кроссплатформенной?

    Ну, хотя бы потому, что скомпилирован в формат dll, который на линуксе, маке, андроиде, айосе - не пойдет. На андроиде еще и архитектуру надо другую. А исходников нет - проприетарный - поэтому не пересобрать.
    Дизассемблирование - это незаконно + сложно и тяжело технически, со мной бы такая работа в 6-7-8-значную сумму вылилась (в рублях), и времени заняло месяцы... ))) На эти деньги можно было бы игровой движок какой-никакой сделать, или еще что-нибудь приличное, и продавать его, вместо того, чтобы портировать DirectX "чтобы было".
    Ответ написан
    Комментировать
  • Зачем делать из названия картинок хеш?

    alsopub
    @alsopub
    Например чтобы более-менее равномерно распределить по подкаталогам.
    Чтобы не было возможности перебрать все картинки.
    Хэш, скорее, должен быть по содержимому, а не по названию, тогда можно еще и дубликаты не хранить.
    Ответ написан
    Комментировать
  • Как отфильтровать случайные всплески в показаниях, взятых с датчика?

    antonsosnitzkij
    @antonsosnitzkij
    студент, житель санкт-петербурга
    можно, например, медианным фильтром
    Ответ написан
    Комментировать
  • Как уйти с распутья технологий?

    @0x131315
    Стратегию уже подсказали: найти любую работу, чтобы кушать, и тем самым выиграть время на изучение чего-то, что поможет зарабатывать больше, и тем самым выиграть еще больше времени, и в конце концов изучить то, благодаря чему будешь работать не на зарплату, а на удовлетворение.

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

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

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

    Конкретный язык нужен кодерам - это те, кто воплощает чужие идеи в коде, т.е. конечные винтики в процессе разработки софта, исполнители. От кодеров требуется только перенести уже готовый алгоритм на требуемый язык, максимально быстро, и по возможности без ошибок.
    Изучив конкретный язык ты можешь стать кодером, но это черновая работа, и по хорошему - временная, просто ступенька на пути становления программиста. Нужно двигаться к архитектору, инженеру, непосредственно программисту в широком смысле.

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

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

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

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

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

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

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

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

    С третьим - придешь, когда поймешь, что тебе это нужно. Из-под палки не учатся.

    Со вторым все понятно: надо либо создать условия, либо отказаться от этой деятельности, и перейти к другой.
    Кто-то отказывается, уходит на другие работы, в основном физические, неквалифицированные, просто чтобы не думать. И как правило остается там до конца, уже не в силах выбраться из болота рутины.
    Кто-то приспосабливается - отгораживает себе уголок, меняет работу на ту, что дает больше свободного времени, начинает работать по ночам, забивает шум наушниками, и т.п. костыли.
    Кто-то кардинально меняет свою жизнь - переезжает в сьемные квартиры, выделяет себе комнату, изолирует ее или устанавливает в доме режим тишины, в общем создает себе полноценные комфортные условия для творчества. Это если удаленка - многие именно из-за невозможности работать дома, предпочитают офисы, или специальные кафе или клубы для работы.

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

    Разрывать такие круги можно лишь одним способом - рутиной: медленным, последовательным и целенаправленным натиском, движением в одну сторону. Грубо говоря перестаешь жить эмоциями и импульсами, вырабатываешь продуманную программу развития, и действуешь по ней, строго, как робот, до тех пор, пока не начнешь получать положительный отклик от работы, пока не придет желание двигаться дальше - это вернулись воля, мотивация и вера в себя.

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

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

    profesor08
    @profesor08 Куратор тега CSS
    Не использовать img, а вместо них div и в CSS через media устанавливать фоновую картинку или нет.
    Ответ написан
    Комментировать
  • Имеет ли смысл использовать REST(ful) API для работы самого вебсайта?

    @VZVZ
    Reverse-Engineer, Software Developer, Architect
    Что значит "гонять все данные через api"? Вернее, как можно НЕ делать этого?
    Что вы понимаете под REST API? Часто его понимают по-разному.
    Как я понял: REST API на самом деле означает никакой не AJAX и не JSON, а просто удобную форму URLов (CRUD и т.д.), а насчет AJAX и формата (JSON, HTML или что) оно никаких правил не диктует.

    Но:
    1) JSON создает тормоза на клиенте в браузере (клиент будет толстый - JSON надо парсить и рендерить в DOM). Ну так пусть API умеет возвращать как JSON ,так и готовый HTML, первый оставим мобилодесктопным клиентам, а второй в браузере - и всем будет хорошо. Примерно так сделано у VK, Facebook и мн. др.
    2) тормоза появляются, когда просто очень много тяжелых запросов и много логики на клиенте. Пример: весь портал гугла. Но никаким API и архитектурой там вообще не пахнет, как по мне.
    3) тормоза появляются, когда ради фигни перезагружают страницу целиком, а не частично. Но можно сделать AJAX. И логика аякса (HTML-версии API) будет не сильно отличаться от JSON-версии, одно легко переделать на другое.
    Ответ написан
    Комментировать
  • Зачем Rails прекомпилирует эссэты?

    b0nn1e
    @b0nn1e
    Alcohol & Ruby on Rails
    В development окружении ассеты перекомпилируется при измении и обновлении страницы, на лету
    В production окружении все ваши Coffee и SCSS будут минимизированы, скомпилированы и объединены в два статических JS и CSS файла, аккуратненько сложеных в папку public/asssets/
    Ответ написан
    Комментировать
  • Wkhtmltopdf в качестве библиотеки?

    AtomKrieg
    @AtomKrieg
    Давай я поищу в Google за тебя
    Command line tools are awesome, but I want a C library.
    No problem. Check out the library documentation.
    wkhtmltopdf.org/libwkhtmltox
    Ответ написан
    3 комментария
  • Какую Linux выбрать в VirtualBox?

    selivanov_pavel
    @selivanov_pavel
    Linux admin
    Virtualbox не предлагает ничего ставить, он предлагает сделать конфиг виртаулки, оптимальный по его мнению для этой системы. Уже неактуальная возможность, на "Linux 2.6 \ 3.х \ 4.х" встанет любой современный дистрибутив.

    На поиграться - лучше ту ОС, у которой самое развитое сообщество. Сейчас это Ubuntu.

    Минимальная загрузка на систему - можно выбрать Desktop Environment полегче, это Xubuntu - ubuntu + XFCE.

    А можно вообще не ставить графику, любая нормальная IDE умеет подключаться к хосту по ssh и там работать. Будете кодить под Linux, не выходя из любимой винды/макоси.
    Ответ написан
    1 комментарий
  • Можно ли восстановить данные в MySQL?

    @Voland69
    Никак не восстановите - поле переполнилось и база обрезала.
    Да и CHAR(11) мало - вдруг номер не российский? с двух-трехзначным кодом страны.
    Ответ написан
    3 комментария
  • Проект стал слишком большим для одного разработчика, что делать?

    begemot_sun
    @begemot_sun
    Программист в душе.
    Поднимаете часовой рейт, аргументируя это возросшей нагрузкой. Вы не обязаны батрачить 24 часа в сутки. Если ему это необходимо, пусть доплачивает за ваши неудобства.
    Из образовавшейся маржи найдите человека, который будет брать на себя часть ваших обязательств перед заказчиком. Контролируйте его.

    Да и в конце концов, ничто не мешает вам сменить проект. Когда вы уйдете, то я думаю он запоет про "отсутвие денег и багтрекинга" по другому.
    Ответ написан
    3 комментария
  • Что лучше показать на первом экране с точки зрения конверсии - кнопку или форму?

    IonDen
    @IonDen
    JavaScript developer. IonDen.com
    На первом экране сделать 2 кнопки:
    я крутой, дайте мне конструктор | я нуб, позвоните мне

    Нажатие на каждую соотвественно откроет второй экран с контентом и при этом уравновесит оба варианта. Так как многие не заметят кнопку, если уже есть форма.
    Ответ написан
    1 комментарий
  • Проект стал слишком большим для одного разработчика, что делать?

    @protven
    Переходите на почасовую оплату. Каждое обращение оплачивается отдельно.
    Ответ написан
    6 комментариев
  • Как спрогнозировать следующую дату визита клиента?

    Юлия Бедросова дает нормальный совет для конкретного бизнеса.
    Надо понимать суму суть поведения клиента, его предпочтения, сегмент рынка на котором работает салон. Да, простая статистика может быть интересна, на некоторых промежутках времени и особенно на больших рядах данных. Но для практики нужны предметные и чуть ли не персональные методики. Кстати, мне почему-то кажется, что мастера салона точнее предскажут поток посетителей (да ещё с учетом сезона), чем математическая модель учетной системы.
    Ответ написан
    4 комментария
  • Как спрогнозировать следующую дату визита клиента?

    nki
    @nki
    bezkart.ru готовая система лояльности
    Я помогаю знакомому автоматизировать салон красоты. Так вот, для каждой услуги он установил время через которое необходимо позвонить клиенту и пригласить на повтор процедуры.
    Просто и со вкусом.
    Ответ написан
    2 комментария
  • Где хранить бесконечность записей (111 * 10^29)?

    Rsa97
    @Rsa97
    Для правильного вопроса надо знать половину ответа
    Это что вы такое собрались хранить?
    95*111*1029 байт ≈ 1034 байт ≈ 1022 терабайт
    Значит покупаете тысячу миллионов миллионов миллионов винчестеров на 10 Tb и получаете своё хранилище.
    Ответ написан
    12 комментариев