Задать вопрос
  • Как (и возможно ли) дотянуться до Junior JavaScript Developer в кратчайшие сроки?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd engineer
    Во первых: совершенству нет предела.
    Во вторых: невозможно объять необъятное и впихнуть невпихуемое.
    В третьих: как ты не крутись, а технологии развиваются быстрее, поэтому отставание неминуемо, как следствие приходится всегда чем-то жертвовать ради чего-то более важного.

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

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

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

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

    Меня на программирование пропёрло весьма рано, лет в 14-15. Я ощущал собственное безграничное могущество, послушная железяка выполняла любое моё повеление, любой мой каприз, при условии, что он правильно сформулирован. Если железка не делала что нужно, или делала что не нужно, то это всегда была моя вина, это значило что я прокосячился. Подобное осознание настигло меня весьма скоропалительно, после чего мозг начал усиленно дисциплинироваться, и количество лютых фейлов пошло на убыль.

    Коммерческая разработка - это, примерно, от 70% времени/сил на дебаг и фиксы, потому что мало где процессы поставлены грамотно. По хорошему до сего дня (а мне под 40) я только одну команду видел, где процессы прям вообще очень хорошо поставлены и мне посчастливилось какое-то время с ними поработать. За эти несколько месяцев я подрос на целую голову. Самостоятельно достичь сходных результатов было бы весьма затруднительно.

    Сам я сменил стек совсем недавно, начал в конце 15 года, и процесс продолжается до сих пор. Сменил я по одной простой причине - во всех моих прежних проектах большая часть логики с бэка уехала на фронт, и прекраснейший jQuery перестал справляться чуть более чем полностью. Он, по прежнему, хорош, но задачи, которые приходится решать, требуют совершенно других подходов. Для себя я выбрал React, но в целом на рынке имеются альтернативы. По моим данным очень большим спросом пользуется Angular 2+.

    Когда говорят о фронтенд разработке, постоянно говорят о технологиях, стеке, но почти никто не упоминает, что не стеком единым... Существенная часть разработки - это, для начала, понять задачу и построить у себя в голове модель. Заказчики бывают разные, от очень толковых, до очень безтолковых. Соотношение первых ко вторым примерно 1% и всё остальное... Т.е. в большинстве случаев тебе скажут минимум, своеобразно, плюс ты это поймёшь по своему. Потом, по ходу пьесы, в самые неподходящие моменты, начнут всплывать подробности, которые: забыли упомянуть; ну это же очевидно, ты же профи; мы сами не знали, это только выяснилось; ну это же мелочи, мы думаем тебе это будет не сложно; а ты не спрашивал; и т.п....

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

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

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

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

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

    Даже если тебе попадается практически идеальный проект, внезапно оказывается, что твоя оперативная память это 5-7+-2 объекта, а удерживать в голове одновременно нужно сотни...

    Зачем я все это рассказываю? Затем, что это реальность, которая для джунов не делает исключений.

    Термин "фигак-фигак и в продакшен" встречается повсеместно, т.к. ресурсы (деньги, время, кадры) практически всегда весьма жестко ограничены и ничего ты с этим не поделаешь.

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

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

    Теперь относительно того что делать - если в бэкграунде нет сильных скиллов по алгоритмике и структурам данных (олимпиады по программированию, универский курс информатики), то прям очень сильно рекомендую прокачать. Будучи наставником на нескольких курсах фронтенда я постоянно встречают студентов, которые "вроде бы" знают язык, но затрудняются скомпоновать пару циклов с условиями, вот буквально просто виснут на неопределенное время, причем без результата. Лично я рекомендую кодварс. Своих студентов я прокачиваю именно там. Достаточно прорешать 30-40 задачек, чтобы базовые скиллы ушли на уровень рефлексов и перестали парить мозг. Правда желательно решать это все с наставником.

    Косвенный бонус тут будет в том, что ты привыкнешь решать задачи на JavaScript. Я когда менял стек, поначалу мыслил на PHP, и подобный финт на кодварс позволил мне переформатировать мышление на JS. Вот мой профиль на кодварс как пруф: https://www.codewars.com/users/iCoderXXI

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

    Понять надо настолько глубоко, чтобы легко и просто, с юморком, рассказывать это любой первой встречной бабушке, да так, чтобы та всё поняла... Это вот прям залог успеха в JS, потому что все остальное держится на этих двух китах. В ютубе имеется курс Зоракса (Zorax) и JavaScript Weird Parts, оба про то же самое, первый на русском, второй на инглише. Кантор, безусловно, крут, но эти двое объясняют попроще и понятнее (имхо).

    После этого прокачиваемся в использовании встроенных методов JS, таких как map, reduce, includes, replace и пр. (на том же кодварс)

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

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

    Потом уже заостряемся на API форм, DOM, AJAX (fetch/axios), вебсокетах, Localstorage и пр.

    И вот только теперь можно переключаться на фреймворки. Проще всего освоить Vue (по слухам), наибольшим спросом пользуются React и Angular, для общего развития так же неплохо бы немного послушать про Ember.JS.

    React только на первый взгляд выглядит простым, на самом деле это только view-библиотека, а в любом нормальном SPA есть много чего еще кроме view, поэтому React всегда идет в компании Redux, Router, и еще целой толпы всего, что тоже придется осваивать, не только с точки зрения API, но и с точки зрения философии (а нахрена оно вообще сдалось?)

    Перед походами на собесы очень желательно иметь портфолио из нескольких готовых проектов, вылизанных стилистически.

    Далее освежаем базу по JS - типы, замыкания, прототипы, и смело топаем по собесам, будучи морально готовыми завалить первые десять.

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

    Еще вроде большие компании вроде Яндекса устраивают летнее обучение, с последующим трудоустройством лучших кандидатов, но это не точно.

    Оптимистичный прогноз - 6-12 месяцев плотного фигачинга и ты в тренде.
    Ответ написан
    7 комментариев
  • Попросили проверить код, на что смотреть нужно?

    index0h
    @index0h
    PHP, Golang. https://github.com/index0h
    Смотря зачем)). Я когда делаю Code Review критерии следующие:

    * Безопасность:
    - Каждый аргумент метода простого типа должен проверяться на тип в случае его проксирования и на граничные значения в случае обработки. Чуть что не так - бросается исключение. Если метод с кучкой аргументов на 80% состоит из поверки из аргументов - это вполне норм))
    - Никаких trigger_error, только исключения.
    - Исключения ДОЛЖНЫ быть человеко-понятны, всякие "Something went wrong" можно отдавать пользователю, но в лог должно попасть исключение со стектрейсом и человеко-понятным описанием, что же там пошло не так.
    - Каждый аргумент (объект) метода должен быть с тайпхинтингом на этот его класс, или интерфейс.
    - За eval как правило шлю на **й.
    - @ допускается только в безвыходных ситуациях, например проверка json_last_error.
    - Перед работой с БД - обязательная проверка данных.
    - Никаких == и !=. Со swtich - единственное исключение, по ситуации.
    - Если метод возвращает не только bool, а еще что-то - жесткая проверка с ===, или !== обязательна.
    - Никаких условий с присваиваниями внутри. while($row = ...) - тоже идет лесом.
    - Магические геттеры/сеттеры разрешаются только в безвыходных ситуациях, в остальном - запрещены.
    - Конкатенации в sql - только в безвыходных ситуациях.
    - Параметры в sql - ТОЛЬКО через плейсхолдеры.
    - Никаких глобальных переменных.
    - Даты в виде строки разрешаются только в шаблонах и в БД, в пхп коде сразу преобразуется в \DateTimeImmutable (в безвыходных ситуациях разрешено \DateTime)
    - Конечно зависит от проекта, но как приавло должно быть всего две точки входа: index.php для web и console(или как-то по другому назваться) - для консоли.

    * Кодстайл PSR-2 + PSR-5 как минимум, + еще куча более жестких требований (для начала все то что в PSR помечено как SHOULD - становится MUST)
    - В PhpStorm ни одна строчка не должна подсвечиваться (исключением является typo ошибки, например словарик не знает какой-то из аббревиатур, принятых в вашем проекте). При этом разрешается использовать /** @noinspection *** */ для безвыходных ситуаций.
    - Если кто-то говорит, что пишет в другом редакторе и у него не подсвечивается, на эти отговорки кладется ВОТ ТАКЕЕЕНЫЙ мужской половой **й и отправляется на доработку)).

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

    * Тестируемость (в смысле простота тестирования) кода должна быть высокая.
    - Покрытие кода обязательно для всех возможных кейсов использования каждого публичного метода с моками зависимостей.

    * Принципы MVC:
    - Никаких обработок пользовательского ввода в моделях, от слова совсем.
    - Никаких ***ть запросов в БД из шаблонов.
    - Никаких верстки/js/css/sql-ин в контроллерах.
    - В моделях НИКАКОЙ МАГИИ, только приватные свойства + геттеры с сеттерами.
    - В моделях разрешено использовать метод save(при наличии такого разумеется) только в исключительных ситуациях. Во всех остальных - либо insert, либо update.

    * Принципы SOLD:
    - Никаких божественных объектов умеющих во все.
    - Если метод для внутреннего пользования - private, никаких public.
    - Статические методы разрешаются только в случае безвыходности.

    * Принцип DRY разрешено нарушать в случаях:
    - Явного разделения обязанностей
    - В тестах (каждый тест должен быть независимым, на сколько это возможно)

    * Работа с БД:
    - Запрос в цикле должен быть РЕАЛЬНО обоснован.
    - За ORDER BY RAND() - шлю на***й.
    - Поиск не по ключам (конечно если таблица НЕ на 5 строк) запрещен.
    - Поиск без LIMIT (опять же если таблица НЕ на 5 строк) запрещен.
    - SELECT * - запрещен.
    - Денормализация БД должна быть обоснована.
    - MyISAM не используется (так уж)) )
    - Множественные операции обязательно в транзакции, с откатом если чо пошло не так.
    - БД не должна содержать бизнес логики, только данные в целостном виде.
    - Не должно быть нецелесообразного дерганья БД там, где без этого можно обойтись.

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

    * О людях:
    - "Я привык писать так и буду дальше" - не вопрос, ревью пройдешь только когда поменяешь свое мнение.
    - "Я пишу в vim-е и мне так удобно" - здорово, код консолью я тоже в нем пишу)) но есть требования к коду, если в них не сможешь - не пройдешь ревью.
    - "Я скопировал этот страшный метод и поменял 2 строчки" - это конечно замечательно, но по блейму автор всего этого метода ты, так что давай без говняшек, хорошо?
    - "Оно же работает!" - вот эта фраза переводится примерно так: "да, я понимаю, что пишу полную хрень, но не могу писать нормально потому, что руки из жо", я правильно тебя понял?))
    - "У меня все работает!" - рад за тебя, а как на счет продакшна?
    - "Там все просто" - не используй слово "просто", от слова "совсем". Вот тебе кусок кода (первого попавшегося с сложной бизнес логикой), где там ошибка (не важно есть она, или нет)? Ты смотришь его уже 2 минуты, в чем проблема, там же все "просто"))

    * Всякое:
    ActiveRecord (это я вам как в прошлом фанат Yii говорю) - полное говно, примите за исходную. По факту у вас бесконтрольно по проекту гуляют модельки с подключением к БД. Не раз натыкался на то, что в тех же шаблонах вызывают save, или update (за такое надо сжигать).
    То, что используется Laravel - это печально((. Что бы выполнить требования приведенные выше, приходится "воевать" с фреймворком.

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

    UPD

    Формализировал данные критерии по ссылочке: https://github.com/index0h/php-conventions
    Ответ написан
    55 комментариев
  • Как развиваться Junior-у PHP?

    @Za0r
    pop()
    по ПЫХЕ:
    - пробегитесь по функциям PHP при работе со строками и масcивами... потренирутесь
    - изучите ООП в PHP, базовые вещи... затем изучите шаблон MVC (он во всех движках, почти во всех фреймах)
    - где-то тут вы уже должны разобраться с нормальными формами в SQL БД
    - расчехлите фреймворк (Yii2 или Laravel) и сделайте любое из тестовых по ссылке выше...
    - углубитесь в возможности фрейма, который выбрали
    ....
    - далее оттачивайте уже архитектуру приложений в рамках фреймворка (сервисный слой, DDD, тестирваоние и прочее)
    - стройте REST, если из фронота -- пробуйте совместить с React или Vue

    Я бы ставку помимо основного стека сделал бы:
    Devops — как вы заметили сами (Linux) и прочее, желательно освоить bash, хорошо разобраться с HTTP, Nginx,
    SQL\NoSQL — это вообще отдельная стезя, но чем ее лучше знаешь, тем более сеньористей :)
    кеширование/очередии прочее с этим связанное
    Сборка, CI, Git и все что с этим связано... AWS, Azure
    ! Еще бы выбрал какой-нибудь взрослый язык (Java, C), чтобы знать как работать с памятью и прочими низкоуровневыми вещами

    Изучить патерны проектирования

    Их не просто изучить, их использовать нужно... у Елисеева пошли уроки по созданию PSR 7 фреймворка, там он рассказывает какие задачи решали создатели тех или иных решений в Зенде/Симфони

    Тоже остановился на беке с Симфони на коне, вместе будем грызть, хочу отметить, что путь как бы тут один, свернуть не туда не получится по инструментами и скилам, если не менять язык

    (с) Максим Федоров
    Ответ написан
    Комментировать
  • Как устроена архитектура современного front-end приложения?

    @pwnz2
    Напишу краткий ответ.

    Начни изучать VueJS. Просто потому что он прост в изучении и начинании и не только, также он приобрел все хорошие стороны таких фреймов как Angular, React, Ember. Его можно использовать просто подключив к странице как и jQuery. Далее иди в сторону бандлеров, изучи webpack и начни использовать готовый шаблон vue-webpack который очень просто можно скачать с vue-cli.
    Ответ написан
    Комментировать
  • С чего начать изучение современных веб-технологий?

    zoroda
    @zoroda
    Необычный Fullstack
    Генерят страницы и на сервере тоже. Но используют для этого тот же код, что и для генерации на клиенте. Я всегда занимался бэкэндом, но захотелось сделать свой фронтэнд с преферансом и поэтессами, благо, некоторые познания в JS уже были. Начал с AngularJS и ReactJS, потом перешёл на Angular2, который мне показался более простым для изучения и более логично построенным. Потом распробовал Vue 2. С него и рекомендую начать.
    Кстати, много полезного не только по Vue, но и по вёрстке вообще, - в курсе Макса Шварцмюллера.
    Ответ написан
    1 комментарий
  • Как влиться в тренд нынешней веб-разработки?

    Блин, 8 лет верстать "по-дедовски")
    Да за это время можно было стать Senior developer или даже выучиться на фуллстак и уехать в какой-нибудь Израиль работать за 4к $

    Препроцессоры я познал за один день. Для CSS использовал сначала less, через месяц ушел на Stylus (советую именно его, так как всякие sass это вообще мрак. Работать в чужом проекте на sass - ад, тогда как stylus прост, при этом более функционален и намного интуитивнее).

    Jade (ныне Pug) узнал просто заканчивая чужой проект. Открыл, посмотрел на то, чего боялся, пришлось почитать что за зверь - работу то делать надо. Оказалось все просто, теперь не знаю как теги раньше писал ручками (со стилями тоже самое было, кстати).

    Сборщик проекта. Для верстки, если выбирать между Grunt и Gulp - без сомнений Gulp. Я очень счастлив, что мне в тот момент подвернулась именно статья про Gulp. Работал с проектами на Grunt (их очень мало) - ну, это просто дерьмо, а не сборщик. Скорость сборки отличается в разы.

    Webpack это конечно повыше уровень, юзать его для верстки не прагматично.

    Флексбоксы в CSS изучаются только на практике, сидеть и запоминать это бессмысленно. 2-3 проекта с подсказкой по флексу и он плотно осядет в голове.

    Вывод: надо просто не бояться нового. Берешь и применяешь новые технологии без страха и зазрения совести. Они быстро вольются в твою жизнь, а без них потом будет дышать тяжело и больно.

    Советую взять готовые проекты у хороших верстаков и просто что-то в них поделать, попеределывать, попользоваться технологиями сразу, не читая нудные статьи про основы.
    Ответ написан
    7 комментариев
  • Как лучше учить английский?

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

    Для этой цели рекомендую посмотреть следующие приложения на Андроид:
    1. Английские Слова 500 - Поможет выучить или повторить 500 наиболее употребимых английских слов.
    2. English Words NGSL - Список из наиболее употребимых слов английского языка. Состоит из 2801 слова и покрывает около 90% языка. Рекомендуется к изучению всем, для кого английский язык не является родным.
    Ответ написан
    3 комментария
  • Как вы (программисты) учились в ВУЗах?

    dsadasdad
    @dsadasdad
    lol
    Херово учился, так подучивал, чтобы не деградировать совсем, не учился даже предметам по специальности, С++ как то не очень интересен был, да и плееры в билдере делать отстойно. Бухал, курил, проводил время со шлюхами, 18 лет че уж там. С вуза поперли, пошел работать на 7 тыщ. Понял, что жизнь гавно, где-то 2010 год был. Выучил английский, немецкий и php, сейчас получаю 70 тыщ+ищу заказы и выполняю их сам и жизнь все равно гавно
    Ответ написан
    12 комментариев
  • Каковы основные принципы регистрации и авторизации через социальные сети OAuth2?

    hbuser
    @hbuser Автор вопроса
    Отвечу сам себе.
    Здесь есть полезная конкретная информация о технической реализации.

    А если вкратце, то...

    Для авторизации, регистрации используется все та же таблица 'users'. Вместе с обычной регистрацией и авторизацией, когда при регистрации (в самом простом виде) в таблицу 'users' добавляются email, password и login пользователя, а при авторизации проверяется соответствие введенных login'а и password'а существующим в базе данных, аналогичным образом используется и регистрация/авторизация через социальные сети. Только в данном случае источником данных о пользователе для его регистрации является не непосредственный пользователь, который вводит данные в форму, а соц. сеть. Регистрация в данном случае достаточно прозрачная, т.е. не видна пользователю. Схема примерно следующая (без особенностей работы Oauth-протокола):


    1) Пользователь выбирает вход через соц. сеть.
    2) Происходит обращение к странице авторизации в этой соц. сети, если человек еще не авторизовывался там. После ввода данных, а если он ранее авторизовывался, происходит запрос на разрешение использования его данных.
    3) Если человек отказывается, то на этом конец. Если дает согласие, то выполняется перенаправление на указанную в настройках Oauth страницу сайта.
    4) У каждого пользователя в соц. сетях есть свой уникальный идентификатор, который можно запрашивать. Для своей таблицы 'users' нужно добавить пару дополнительных полей (например, вот такие): auth_via (enum('native, 'vk', 'mailru', '...')) - для обозначения типа регистрации пользователя, и social_id - здесь будет храниться уникальный идентификатор в соц. сети. Если нужно хранить какие-то специфические данные этого пользователя из соц. сетей, то можно создать доп. поля для этих данных.
    5) После того, как пользователь дал разрешение на использование его данных, необходимо запросить нужные данные от соц. сети, в т.ч. и идентификатор пользователя в соц. сети. Вот здесь и начинается невидимый процесс регистрации. Нужно проверить есть ли в БД пользователь с таким social_id, если нет, то вставляем social_id, данные пользователя из соц. сети, по необходимости, в БД. Все, пользователь зарегистрирован.
    Если же данные о пользователе есть, то необходимо запросить актуальные данные из соц. сети, сравнить их с теми, что в базе и если они изменились, то обновить их и в своей базе данных, если нет, то просто переходим к следующему шагу.
    6) Создается сессия с данными пользователя.

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

    ca4a4b263fd1424085988c9deaeb6d5b.png

    Для пользователя, зарегистрированного из соц. сети пароля и логина, естественно, нет. Они нужны для авторизации. А т.к. пользователь авторизуется с помощью своих логина и пароля в соц. сети, то и указывать здесь нечего. И еще, можно при авторизации, к запросу проверки логина и пароля, добавить условие

    'AND WHERE `auth_via`="native"'

    , чтобы исключить пользователей, зарегистрированных из соц. сетей.

    Как видно, для каждого пользователя в таблице создается внутренний (внутрисайтовый, если так можно выразиться) первичный, автоинкрементный ключ. Соответственно, нет разницы для логики сайта между пользователем, зарегистрированным через соц. сеть и через сайт. Если говорить об интернет-магазине, то, для привязки заказов к пользователю, можно использовать единый, внутренний идентификатор ID.
    Ответ написан
    3 комментария
  • Как правильно реализовать клиент-сервер приложение на Java?

    Ну если банальные ответы, которые сразу приходят на ум
    1 2 ) Разбивать все на куски размером N байт(чтобы можно было считывать). При начале посылки файла отправляешь сколько кусков какого размера будет и этим можно реализовать докачку.
    3) не очень понимаю в чем проблема. просто передаешь

    P.S. Для понимания клиент-сокетов на Java для начала почитайте link
    Ответ написан
    Комментировать
  • Open source проект управления умным домом

    Archie_RU
    @Archie_RU
    Вот хочу помочь, но пока не очень представляю чем.
    Java — да.
    Ответ написан
    2 комментария
  • Что разрабатываю Java и .NET программисты?

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

    Конторы, которые будут Вас нанимать, скорее всего, иллюзий питать не будут. Вы — джуниор, спрос — соответствующий. Глубокое знание конкретного языка не потребуется, а если будет написано в резюме — не поверят. Зато должны спросить, чем отличается List от Vector, что в каких случаях быстрее работает, Какая хеш-функция Вам кажется хорошей, как работает Map, что такое функция сложности, чем отличается, на Ваш взгляд, хороший код от плохого и тому подобные вещи.

    В таком случае, Вам нет смысла изучать «Swing, JSP, JSF, AXIS, JDBC» — максимум, Вам понадобится понимание того, что это такое и зачем используется. Общие идеи и концепции.

    Есть и другая проблема: Обычно, требуется «опыт от года». Вопрос, где взять первый год — за кадром. Так что сначала надо устроиться и начать набирать опыт. В процессе Вы сами поймете, что Вам ближе.

    Если исходить из вышеуказанной логики, то изучать Вам надо и то, и другое — для расширения кругозора. Глубокого понимания Вы не сможете достичь тупо по причине недостатка опыта в реальных ситуациях, зато Вы сможете прособеседоваться на более широкий набор должностей(и ява, и шарп) — быстрее начнете набирать реальный опыт.

    Ну и чтобы ответить хоть на что-то из того, что спрашивалось. :)
    Ява — в большинстве своем back-end некоей «бизнес-логики» в самом широком смысле. Начиная от движка интернет-магазина и заканчивая сервером ММОG.

    Шарп — Либо UI, под винду, back-end к ISS, если уж случилась такая неприятность, что сайт работает на нем.

    PS. VS — эпическое убожество, средой разработки ее можно назвать с натяжкой, а использовать можно только по причине того, что на C++ писать тупо не на чем больше(ну мы же не будем всерьез рассматривать Eclipse, правда?)
    Ответ написан
    5 комментариев