• Для чего идеальна MongoDb? Примеры приложений, где монга будет лучше mysql?

    usdglander
    @usdglander
    Yipee-ki-yay
    MongoDB и MySQL - разные вещи.
    MySQL служит для хранения связанных данных, контроля их целостности и манипуляции с ними, а Mongo хранит документы, которые по-сути никак не зависят от других документов, но к ним осуществляется быстрый доступ. Надо быстро отображать данные на сайте не собирая их все по куче таблиц - используйте Mongo, нужна операция с данными и бизнес-логикой - используйте MySQL.
    Альтернативный вариант - всё хранить в MySQL, а данные на сайт выводить с Mongo, периодически производя выгрузку из Мускула в Монгу.
    Ответ написан
    1 комментарий
  • Для чего идеальна MongoDb? Примеры приложений, где монга будет лучше mysql?

    @xfg
    Высокопроизводительные распределенные интернет-приложения. Конкретные примеры: amazon.com, netflix.com, ebay.com. NoSQL движение возникло как ответ на проблемы масштабируемости. Реляционные базы ориентируются на требования ACID и как следствие имеют проблемы с горизонтальным масштабированием. Для таких баз необходимо реализовывать шардинг на уровне приложения. Но тогда будет необходимо отказаться от ACID, объединения таблиц и контроля целостности. В таком случае реляционная база теряет все козыри перед NoSQL. Но оставляет на плечах разработчика заботу о шардинге.

    Интернет забит вопросами о том как жить без транзакций в NoSQL. Но бизнес-процессы в реальной жизни не являются транзакционными. Вы не можете человека, который покушал в вашем ресторане, а теперь отказывается платить по счетам заставить сделать роллбек вашей еды. Фактически посетитель вам бросил эксепшен. И даже если вам удастся извлечь еду из вашего посетителя, то маловероятно, что она будет готова к последующему употреблению. Но можно взыскать с него все затраты через суд и придти таким образом в согласованное состояние. Любому бизнесмену это очевидно. Но программисту нет. Он хочет транзакционно. Но пишет систему для автоматизации бизнес-процессов. Парадокс.
    Ответ написан
    7 комментариев
  • Какие курсы по php выбрать?

    Minifets
    @Minifets
    Hello world!!!
    В последнее время подрабатываю репетиторством по PHP, для подготовки джунов в штат.
    Появилась идея сделать бесплатный онлайн курс по php 7, но неизвестно насколько это актуально с уже имеющейся базой бесплатных и платных курсов.

    Если есть желающий, то можете написать на gmail. Если наберется группа, то старт будет в январе 2019.

    P.S. Надеюсь не забанят :).
    Ответ написан
    Комментировать
  • Как получить авторские права на приложение от разработчика?

    CityCat4
    @CityCat4
    //COPY01 EXEC PGM=IEBGENER
    чтобы я имела авторские права на работу, которую я заказываю (мобильное приложение)?

    Никак.

    Внимательно читаем ГК РФ, глава 70 АВТОРСКОЕ ПРАВО. Рекомендую прочитать всю главу, особенно статьи 1288 - 1297.

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

    SecurityYourFingers
    @SecurityYourFingers
    I make other things, but i know that without your
    Единственный 100% способ: необходимо купить левый телефон. Конкретно вы с этого телефона не должны заходить в интернет через домашний вайфай. Подключаетесь к общественной точке , например макдональдс.Для пущего эффекта используйте VPN (20 рублей на день) Заходите на любой хостинг, платный\бесплатный, регаетесь(вводите ложные данные(данные паспорта не проверяются)). Заливаете сайт. Вырубаете мобилу. зарываете телефон к костре.
    Ответ написан
  • Вы в браузере набрали адрес сайта, нажали Enter. Расскажите максимально подробно о технических процессах происходящих далее?

    Deerenaros
    @Deerenaros
    Программист, математик, задрот и даже чуть инженер
    Действительно, уважаемый. Это слишком. Вряд ли я затрону все тонкости, но попробую наметить примерный путь:

    0) Пользователь вбивает в адресную строку браузера адрес сайта (нажимая клавиши на клавиатуре, которые замыкают определённую дорожку в матрице, по которой происходит определение нажатой клавиши, что через шину USB в какой-то момент передастся OS, где это поймает HID-драйвер и вызовет определённое прерывание, что OS передаст как событие/или_ещё_как в программу, которая вызовет соотвествующую функцию из API менеджера окон, которая изменит содержимое строки и в результате когда-то будет перерисован UI-элемент, а если нажат был Enter, то начнётся следующее).
    1) Браузер вытащит из input'а строку с запросом и посмотрит, похоже ли это на адрес. Если да, то добавит недостающие уточнения (например, http или file протокол, порт и подобные довольно стандартные вещи). Если нет - то скорее всего создаст запрос в поисковую систему, установленную по умолчанию (я более не буду опускаться до таких бессмысленных деталей, как вызовы API-функций, иначе я буду набирать это сообщение ОЧЕНЬ долго). В любом случае на выходе мы по сути получим URL, который надо загрузить. Протокол file:// мы рассматривать не будем, ftp далеко не везде есть, https:// на не хватит вечности, так что остановимся на http, который по сути есть tcp/ip по умолчанию на 80 порту с определённым форматом общения.
    2) Окей, url есть. Теперь нам нужен адрес, к которому обращаться. Так как http это tcp/ip - нам нужен ip адрес. Здесь нам помогают dns-сервера. Обычно, нормальный провайдер устанавливает у себя кэш-сервера dns, которые не обращаются по стопицот раз за vk.com к ответственному серверу com-зоны. Давайте не будем отвлекаться на то, как происходит там общение, если что - вот (вики тем хороша, что часто содержит внизу релевантные ссылки). Скажу лишь то, что на выходе мы получаем ip адрес(а).
    3) Имея адрес мы можем запросить страницу. Собственно, всё что после первого слэша - это как-бы параметры для http-сервера: какую именно страницу запрашивать, он всё же не телепат. Конечно, можно было бы немного схитрить и отправить читать про tcp/ip, но ведь существует и shared-hosting. Ограничемся лишь его упоминанием. Собственно, по полученному адресу отправляется GET запрос, который и обрабатывает сервер, находящийся по полученному IP-адресу.
    4) Сервер же, получив адрес, начинает распарсивать строку, медленно вытягивая нужные данные из баз-данных и настроек, выполняются сотни скриптов, иногда делается ещё не одна сотня различных запросов на другие сервера (здесь и разного вида метрики и разного вида HADOOP и т.д.). Пройдя сквозь скрипты и темплейторы в самом конце мы получаем html-страницу, готовую к употреблению. Её-то сервер и отправит в ответе (после заголовков, конечно).
    5) Вот и началось самое интересное. Получив html страницу браузер начинает жутко надругаться над CPU, HDD и GPU, попутно сжирая тонны RAM и мусоря в swap. Виной всему нереальные для полного соблюдения стандарты от небезызвестной w3c.org. Для облегчения многие делают костыли, вроде webkit, а некоторые и вовсе забивают на него и пилят свой стандарт с преферансом и картёжницами (впрочем, в последнее время становиться лучше). Здесь снова начинаются сотни вызовов API ОС, windows manager'а и прочих библиотек, вроде boost, qt или libpng. В ходе работы в RAM строится макет, по которому потом строится нечто вроде PDF (тоже сильно векторный), что, потом, обрабатываясь быстрыми шейдерами на GPU, выдаётся на экран. Опять же, многое пропущено, но вряд ли кому-либо, кроме парня в свитере с оленями, действительно интересно, как работает GDI, DirectX или OpenGL.
    6) Ах да, мы же забыли про тысячи js-скриптов, миллионы картинок и анимации с котиками, а также о таких дополнительных плюшках, как flash-player или java-weblets. В кратце, что js, то и flash и java - это виртуалка, со специальной архитектурой. Они, виртуалки, конечно разные (хотя flash и js довольно похожи, ещё бы - ECMAScript один и тот же). JS - самый интегрированный внутрь браузера, он же и самый медленный чисто визуально (ибо последние два имеют доступ к быстрому GPU), хотя самый быстрый в попугаях. Второй постепенно вымирает и представляет из себя, так же как и третий специальную shared-библиотеку, о которой браузер как-нибудь узнал и которой скармливает специальное содержимое помечанное специальным тегом html. Третий уже почти умер и встречается лишь изредка или в каком-нибудь энтерпрайзед со страшным legacy-базой. Ну здесь из сылок разве только гугл. Ибо сколько всего - даже не сообразишь. Да и вообще, эта тема ещё скучнее GDI, DirectX и OpenGL и к свитеру с оленями требуются ещё очки с толстенными стёклами, дающие стопицот к терпению и задроству над матаном. Если в кратце, то в случае JS, всё что было загружено в память и не думает выгружаться и формирует этакое дерево - DOM, над которым с помощью специального API и происходят модификации. При этом, перед тем как исполниться, весь JS-код компилируется, в нативный для VM байт-код. То же самое в общем-то и со вторым и третьим, разве только они не имеют доступа к DOM и организовать его - дело тех ещё костылей. Ах да, забыл ещё про Silverlight (или как оно там пишется), который сдох, не успев родиться. Так же как и Java, жив в серьёзном энтерпрайзе, не поскупившийся не "дешёвую" поддержку MS.
    7) Ну... А дальше пользователь нажимает на нужную гиперссылку и всё по новой.

    За кадром остались такие костыли, как ajax, websockets и прочая асинхронная ересь. С ней всё в миллионы раз сложнее. И к очкам со свитером потребуется ещё и... а чёрт их знает, что они там ещё носят. Ну да ладно, я искренне завидую тем парням (и девушкам), которые разбираются во всей этой машине. Целиком. Ибо это лишь верхушка айсберга. Разбавленная не лучшей памятью и ужасным гуглом.

    P.S. Не бейте сильно за грамматические и синтаксические ошибки. Спеллчекер приказал долго жить, да и 5 утра как никак.

    UPDATE
    На хабр выложили неплохой перевод дающий некоторое представление, как браузер ругается над памятью и процессором. Хотя и весьма поверхностное,
    Ответ написан
    26 комментариев
  • Что такое Less и Sass?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Лень двигатель прогресса. Хороший пример - принцип DRY - Don't repeat yourself. Я весьма подозреваю что вы стараетесь соблюдать этот принцип когда делаете макеты или чем вы там занимаетесь. Так же я весьма уверен что вы хотя бы пытались чуть автоматизировать рутину своей повседневной работы. Так же у вас могли быть ситуации когда вы переиспользовали какие-то элементы. Мало ли.

    Так вот... CSS это тупая таблица стилей. Селектор и стили, ничего сверх умного тут придумать нельзя. Лет 5-10 назад было довольно модно держать один мегажирный CSS файл на 10К+ строк и радоваться жизни внося все больше изменений и т.д. Соответственно даже если вы соблюдаете всякие правила модульной верстки и все такое, у вас возникает несколько проблем:
    • организация стилей, то есть держать все в одном файле не удобно особенно когда проект длится годами
    • Дублирование стилей и селекторов. По мере развития проекта появляются какие-то снипиты которые можно реюзать. Так же у вас может появиться масса однообразных селекторов отличающихся лишь немного. При модульных подходах вложенности редко имеет место быть но все же имеет. Но не будем забывать что большинство фигачит селекторы просто так. В итоге если мы переместили блок или переименовали класс какого-то блока нужно отредактировать еще массу селекторов.
    • Привязка размеров и параметров к другим стилям, например у вас в стилях задана ширина блока, от нее зависят другие параметры, отступы для других блоков и т.д. Да, в css3 появился calc для этого но это было относительно недавно и только с недавних пор можно почти без опаски использовать эту штуку.
    • Таблицы стилей, как и HTML ориентированы на удобный разбор этого добра машиной, но не человеком. Человек же существо ленивое и как-то вот лень лишний раз скобку поставить или точку с запятой. Просто лень.


    Есть так же хорошее правило, или идея если хотите.... Если код можно сгенерить - его лучше сгенерить. То есть для решения всех выше перечисленных проблем придумали препроцессоры. Они как бы были и раньше всех этих scss/less/stylus но как-то не решали всех проблем и т.д. Что в итоге было предложено (перечисляю в том же порядке что и в списке выше).

    • У CSS есть такая штука как @ import. Но не очень круто импортировать сотню стилей в продакшене. Стоит сделать так что бы все стили были склеены при сборке проекта. Эта идея в итоге развилась и если разработчик использует это дело правильно, можно зайти в любой файл со стилями и увидеть список всего от чего зависят эти стили. Какие стили подключаются и т.д. Причем один файл с зависимостями может быть подключен в нескольких файлах а препроцессор сам разберется как и куда все вставлять сгенерив максимально оптимизированный по структуре файл. А разработчик получил четкую структуру файлов и возможность быстро найти где что и от чего зависит.
    • С селекторами проблему предложили решить наиболее логичным вариантом. Если у нас есть вложенные селекторы, то имеет смысл определять их внутри блока этого селектора. Это существенно упрощает поддержку стилей. Так же для управления снипитами и прочим добавили миксины - эдакие параметризованные или нет функции которые выплевывают шматок CSS. До появления штук вроде autoprefixer это был единственный способ писать поддерживаемые стили, использовать плюшки CSS3 и вообще новые плюшки и не сойти с ума от префиксов. Префиксы это только пример, там могут быть самые разные штуки позволяющие грамотно производить реюз стилей
    • Проблему зависимостей значений стилей друг от друга решили... собственно самым очевидным способом - переменные. Это удобно, легко поддерживать и в умелых руках это мощный инструмент. Нужно поменять базовые цвета - не нужно лазить по 100500 блоков и править значения руками, можно поправить переменные и все будет хорошо.
    • Насколько я помню SCSS/LESS не стремились решить эту проблему. Какие-то решения образовывались сами собой с течением времени. В плане минимализма и выразительности пожалуй сейчас самая крутая штука это stylus.


    Что в итоге произошло. В один прекрасный момент какие-то там рубисты придумали SCSS (они вообще не любят все что не в стиле ruby в плане минимализма и выразительности). Затем чуваки подумали и сказали, SCSS это круто но почему-то они используют синтаксис знакомый именно Ruby разработчикам а не обычные для CSS конструкции. В итоге реализовали LESS, причем его уже реализовали на javascript, что с наличием node.js позволило это все добро еще на одной платформе собирать. А так как под эту платформу и так плодили препроцессоры оно удачно вписалось.

    Далее уже шли какие-то модификации дальнейшие, вроде того же Stylus, где синтаксис упростили просто до нельзя.

    Личное мнение. На сегодняшний день я не вижу смысла использовать чистый CSS хоть на малых хоть на больших проектах. Вот вообще никакого.
    Ответ написан
    3 комментария
  • Как правильно перевести на английский "HTML вёрска"?

    Moskus
    @Moskus
    Если оставить сарказм в стороне, то нужно начать с того, что не любые термины и выражения имеют буквальный перевод. В русскоязычной среде получилось так, что подготовка кода HTML стала ассоциироваться с версткой. В англоязычной среде этого не случилось. По-английски не говорят "HTML-верстальщик", говорят "HTML-разработчик". Потому, никакая не "верстка", а "код". Кроме того, некоторые сопутствующие проблемы не воспринимаются, как часть общего процесса верстки. Соответственно,
    1. HTML code
    2. I prepare/write/develop HTML code
    3. Exporting images for Web (front-end)
    Ответ написан
    3 комментария
  • Что учить frontend разработчику?

    edli007
    @edli007
    full stack, team lead
    Да тут за 2017 еще все изучить...
    Существует специальный роадмап на гитхабе для фронтендеров
    https://github.com/kamranahmedse/developer-roadmap
    Ответ написан
    1 комментарий
  • Что учить frontend разработчику?

    bmind
    @bmind
    Software Engineer
    State of JavaScript 2017 - путеводитель по использованию технологий.
    А тут перевод на хабре.
    Ответ написан
    Комментировать
  • В каком языке, в какой области программирования меньше текучки "знаний"?

    AlexMaxTM
    @AlexMaxTM
    Поймите одну простую вещь. Чем сложнее путь, тем меньше у вас конкурентов. Успехов добиваются только те, кто с удовольствием берется за самое сложное. А победителем станет тот, кто сделает то, что не смогли сделать другие.
    В тоже время соглашусь с тем, что не обязательно учить что-то новое и модное. Тут же цель какая? - бабки заработать. А заработать их можно только тогда, когда сможешь решать проблемы других людей. Если багажа опыта и знаний хватает на то, чтобы решать актуальные проблемы, тогда не обязательно владеть всеми технологиями.
    Клиенту чаще всего нужно всё сразу и ещё вчера. Сможете ему помочь в этом на старой базе знаний, значит сможете заработать.
    Ответ написан
    6 комментариев
  • Что учить frontend разработчику?

    1. Сначала учим фундаментальщину (как работают компьютеры, сети и браузер, http, основы программирования).
    2. Затем изучаем как работают конкретные веб-технологии (html, js, css, как всё это парсится браузером и рендерится в веб-страницу, учимся верстать и использовать js, книжек и курсов масса).
    3. Далее изучаем технологии, которые всё это автоматизируют, упрощают и абстрагируют (фреймворки, бутстрапы, реакты, сборщики, jquery, новые стандарты, гриды итд итп).
    4. Практика, применение изученного, выбор специализации (зависит от того, что хотите далее делать во фронте - это может быть просто вёрстка, создание интерфейсов или визиуализация данных, а может быть и работа с графикой\аудио\видео, тренды (сейчас это react, bootstrap, foundation, babel, es6, d3, RxJS, функциональное программирование)), далее развиваться на протяжении жизни можно до бесконечности. Но без первых пунктов это всё ничто.
    Ответ написан
    Комментировать
  • Может ли один хороший веб-разработчик заменить команду?

    DMGarikk
    @DMGarikk
    Lead Software Developer
    Написать сможет, только это займёт очень много времени.
    А вот про полноценную поддержку можно забыть.
    P.S. Ах да...потом он просто умрёт от перегрузки
    Ответ написан
    1 комментарий
  • Может ли один хороший веб-разработчик заменить команду?

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

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

    В третьих - вопрос рисков. Один человек может заболеть, уволиться, умереть наконец.
    Команда и распределение обязанностей страхует эти риски.

    Если говорить про приведенный пример в виде сайта Аэрофлота - мой опыт работы с enterprise компаниями, говорит что задачка "нам нужно сделать новый баннер на главной странице" оформляется в виде небольшого ТЗ страниц на 70-80, включает в себя предварительную аналитику, 5-6 вариантов дизайна, исследования фокус групп, - и это все не говоря о юридической части работы. Сможет ли это все сделать 1 человек за приемлемое для заказчика время - ...
    Ответ написан
    1 комментарий