• Почему не могу найти работу Junior'ом C#?

    @kttotto
    пофиг на чем писать
    Это не резюме, это набор слов, ничем Вас не выделяет из общей массы и даже делает низовым в списке общей массы.

    1. Такой кучи тегов даже у меня нет)) Если Вы знаете названия технологий, не говорит о том, что Вы знаете сами технологии. С Вашим опытом никто не поверит, что Вы имели реальный опыт со всем этим, а не просто hello world написали. Выберите те, в которых по Вашему мнению Вы лучше всего разбираетесь.

    2.
    Отличное знание WinForms, ASP.NET, LINQ и WPF. Паттерны: MVVM, MVP, Repository, IoC.

    Для третьекурсника звучит самонадеяно. При такой формулировке на техническом собеседовании будут проверять "отличное" знание и я почти уверен, что Вы его провалите. Лучше сказать что-то подобие: имел опыт работы с, для реализации использовал технологии, имею <начальные> навыки работы с и т.д.

    3.
    Занимался исправлением мелких багов, написанием небольших SQL-запросов и unit-тестов, решал небольшие задачи.

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

    4.
    Если вспомнить css и html

    Вот такое никогда не пишите. Лучше соврать или преувеличить, или даже написать "Отличное знание", но не так как Вы здесь сформулировали.

    5. Не нужно оставлять ссылки на каждый проект в репозитории. Либо один, самый интересный на Ваш взгялд, либо одна ссылка на сам репозиторий. Работодатель пойдет туда только, если Вы заинтересуете его, не раньше. И ему пары файлов хватит оценить ваш уровень. Он не будет делать ревью всех Ваших проектов.

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

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

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

    Берешь гранату, закрепляешь в системнике, выдергиваешь чеку и поджимаешь спусковой рычаг крышкой корпуса... )))
    Ответ написан
    6 комментариев
  • Насколько адекватно требовать домашнего развития от разработчиков?

    @MamaLuyba
    все просто: если специалист ценен, то даже если он скажет, что в свободное время употребляет собак в разные места, то ему ничего не скажут, ибо он тогда может огорчиться и уйти.
    а если не ценен, то тут можно что угодно придумывать. "охладей к жене, но не к программированию!", "лучше дочь проститутка, чем ты, лежащий на диване!", "продай друзей, продай родных - купи лампового кнута и УЧИ!"
    Ответ написан
    2 комментария
  • Изучение фронтэнда/JS?

    BBmike
    @BBmike
    вот Вы дошли до замыканий,контекста , bind, call, а сколько у Вас проектов с использованием материала и знаний из прошлых глав, которые сделаны самостоятельно с нуля? сколько задач по js решено? есть ли github и работаете ли с ним?
    Ответ написан
    Комментировать
  • PHP+JS Трудности с выбором учебно-боевого проекта?

    Nikolino
    @Nikolino
    Сделайте приложение по оптимизации и ресайзингу картинок, по типу tinypng.com

    Пользователь может залить картинку любого размера, ваше приложение должно "сжать" эту картинку без потерь.
    Пользователь также может выбрать фичу уменьшения размера изображения, допустим, до 50% от исходного изображения. То есть картинка 800х600 будет уменьшена до 400х300 и сжата без потерь.

    Если усложнить задачу, то позволить пользователю заливать zip/rar архивы с изображениями, также указывает свою почту куда скинуть итоговый архив с обработанными изображениями.

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

    Но это может быть слишком сложно для новичка. Поэтому:

    Поэтому простой блог с админ панелью (на bootstrap).

    Усложняем:
    В блоге есть посты, категории и теги. Пост может быть в нескольких категориях. У категорий могут быть родительские категории. Ajax комментарии и лайки к постам и комментариям, комментарии должны быть вложенными (как на хабре или vc.ru).

    Еще усложняем:
    Пост добавляется через WYSIWYG редактор, в редакторе можно добавлять картинки, которые будут сохраняться на сервере. Желательно, чтобы картинки можно было ресайзить прям на лету. Лучше использовать какой-нибудь filemanager.

    Еще усложняем:
    Регистрация/авторизация пользователей через соц. сети.

    Еще усложняем:
    Сделайте полнотекстовый поиск по блогу, в том числе и по комментариям. Освойте Sphinx или Elasticsearch, научитесь устанавливать и настраивать все это на фреймворке (Laravel или Symfony).
    Познакомьтесь с Redis, научитесь кешировать данные из базы в redis'e. Обновляйте кэш, когда кто-то добавил комментарий/like или вы добавили пост.

    Еще усложняем:
    Познакомьтесь с Websocket'ами, научитесь делать так, что если кто-то ставит лайк под постом или комментарием, то все, кто онлайн, видят сразу, что кол-во лайков у поста/комментария увеличилось.
    Чтобы со всем этим поиграться, освойте Docker.
    Покройте приложение простейшими Unit тестами.
    Ну и конечно же, коммитьте это всё на Github(Bitbucket).

    Если всё это получилось, то вы уже почти готовый fullstack больше в сторону backend'a. Для middle backend'ера еще нужно подтянуть Rest API, чтобы умели api'шки пилить (с авторизацией), и желательно еще одну СУБД, лучше PostgreSQL, а также анализ запросов к БД (индексы, explain и т.д.). Для полноценного fullstack'a нужно освоить получше JS, верстку(БЭМ) и frontend framework'и: Vue.js, React, Angular, чтобы уметь в одиночку запилить SPA приложение, которое по api тащит данные с вашего же сервера.

    Сейчас меня закидают помидорами потому, что сказал middle, и кто-то скажет, что middle это больше n лет реальной разработки. Но описанное выше решает большую часть всех повседневных задач в коммерческих проектах. Если научились делать это, значит научитесь решать и остальные задачи, пусть и немного (или много) погуглив. Здесь на тостере есть те, у кого 5 лет опыта в разработке, но по-прежнему junior'ы, потому что всё время пилили лендинги или сайты-визитки на 3-5 страниц.
    Также следует сказать, что грейды (junior, middle, senior) сильно отличаются в разных компаниях

    Всё описанное это дело в лучшем случае, полугода. В худшем случае может затянуться и на года.

    Скорей всего такого не случится, что вы будете всё время заниматься только этим блогом. На протяжении обучения у вас появится желание сделать что-то еще, потестировать то или это, поиграться с какой-то технологией (Sphinx, Elasticsearch, Redis, RabbitMQ и т.д.) отдельно, или проштудировать верстку, js, возможности фреймворка отдельно. К проекту вы будете возвращаться время от времени, почерпнув знания из промежуточных тестовых проектов.
    Ответ написан
    Комментировать
  • Как лучше организовать код?

    Alex_Wells
    @Alex_Wells
    PHP/Kotlin
    На TS есть фреймворк, называется Nest. Он изначально использует модульную структуру, и там она реализована достаточно хорошо. Гляньте.

    Далее как я делаю в Laravel проекте:
    - /vendor - зависимости компоузера, в виде сторонних библиотек и компонентов symfony/laravel. Там есть весь базовый функционал, как, например, работа с БД. Такие зависимости в любом случае будут тесно связанны с логикой приложения, и думать об их удалении не стоит вообще. Максимум, что вы можете - построить слой абстракции над /vendor, но это ПЛОХАЯ идея.
    - /app/Ship - увидел это в другом фреймворке, называется Apiato. Сам по себе он хрень, но сама идея мне понравилась. Этот "корабль" - слой твиков, временных фиксов, загрузчиков и другого, что касается каких-то базовых, недостающий частей фреймворка/библиотек, и используется всемя модулями в проекте. Например:
    • загрузка модулей. Так как для laravel нету нормальной системы, пришлось написать свой костыльчик. Лежит он в ship.
    • обработчик исключений
    • ядра (хттп и консольное)
    • твики для миграций
    • общие трейты, скоупы
    • миксины
    • общие миддлвейры


    В общем все то, что относится ко всему проекту в целому. Структура - хаотична.

    Таким образом в третьем, финальном слое, у меня только чистая бизнес логика:
    - /app/Containers - контейнеры - пафосное слово на замену модулям. Идея та же. В каждом контейнере, в корне, лежит класс с названием контейнера, в котором находятся такие штуки как: краткое название для авто-префикса ресурсов, список провайдеров и миграций (назовем их "штуками из фреймворка", к структуре не относятся).
    Структура каждого контейнера:
    • API/ - все, что касается хттп апи приложения
      - Controllers/ - контроллеры хттп
      - Requests/ - классы form request хттп
      - Tests/ - функциональные тесты этого апи
      - routes.php - файл раутов
    • Broadcasting/ - все, что относится к броадкастингу через сокеты
      - Events/ - сами классы эвентов
      - channels.php - файл регистрации каналов броадкастинга
    • Configs/ - конфиги этого конкретного контейнера (и НЕ его зависимостей)
    • Extra/ - иногда бывает что-то, немного выходящее за рамки контейнера, но еще не входит в Ship. Идет сюда.
    • Middlewares/ - хттп миддлвейры
    • Database/ - все, что связано с базой данных
      - Factories/ - файлы пхп, регистрирующие фабрики моделей ларавель
      - Migrations/ - классы миграций
      - Seeders/ - сидеры базы
      - Setup/ - классы-фабрики, обложка над Factories
    • Enums/ - энамы
    • Exceptions/ - исключения
    • JsonResources/ - гсон ресурсы
    • Models/ - eloquent модели
    • Providers/ - провадйеры
    • Services/ - маленькие классы-сервисы, содержащие всю бизнес логику, не привязанные к ХТТП. Каждый сервис выполняет либо одну задачу, либо несколько мелких задач одного типа. Singleton
    • Traits/ - трейты


    Все, что я выше указал - либо часть самого языка (как трейты), либо часть фреймворка Laravel. Гуглите.

    Есстественно, под разные фреймворки внутренняя структура каждого контейнера может и будет менятся.

    PS: БД одна для всего проекта. Зачем вам разные БД, когда есть разные таблицы?)
    PS2: то, что вы себе представили - называется микросервис. Выполняет какой-то небольшой набор задач, имеет отдельную базу и вообще изолирован от всего остального. Но раз вы задаете такие вопросы, вам они точно не нужны.
    Ответ написан
    5 комментариев
  • Как лучше организовать код?

    ThunderCat
    @ThunderCat Куратор тега PHP
    {PHP, MySql, HTML, JS, CSS} developer
    Во первых - ООП, иначе нет смысла заморачиваться с крупным проектом, да и функциональный подход сегодня вообще в проектах больше чем "свой микроблог" никто не использует, это не рационально.
    Так же откройте для себя MVC и возьмите какой-то фреймворк в котором все это уже нормально реализовано, в итоге время потраченное на прочтение документации и написание контроллеров и моделей к проекту будет в разы меньше чем вы потратите на свое кошмарное велосипедостроение. Кроме того, построенный по вашим наброскам Титаник и показать то кому-либо будет стыдно, а знания любого современного фреймворка напротив - будет большим плюсом.
    Удалив модуль и БД мы повлияем на работу других модулей. Изменив структуру БД мы повлияем на работу других модулей.
    SOLID, DRY, KISS...PSR4 и много других страшных аббривиатур вам помогут )
    Ответ написан
    8 комментариев
  • Где взять тестовые данные для дизайна?

    paulradzkov
    @paulradzkov
    Дизайнер, верстальщик, начальник отдела UI
    https://www.lists.design
    Они же на GitHub https://github.com/listsfordesign/Lists

    Если вы рисуете в Sketch, то https://www.invisionapp.com/craft#data
    Ответ написан
    Комментировать
  • Посмотрите, пожалуйста, как вам шапка сайта?

    Kadzi
    @Kadzi
    Ом
    5bff03414d18f239051852.jpeg

    1. сделаем навигацию в нужном порядке: сначала блестяшки, доставка и оплата с оффером, фактоиды о себе и наконец, контактная информация.
    2. покажем, что ссылки это ссылки, линию делаем с прозрачностью, чтобы не мешала, напишем-ка все строчными, по-европейски.
    3. выровняем лого, навигацию и телефон по 1 линии — верхняя граница строчных
    4. напишем правильно мобильный телефон, без мусора
    5. упростим лого
    6. используем 1 гарнитуру
    7. сделаем менее агрессивный розовый
    8. вынесем цитату, сделаем висячую пунктуацию, добавим автора
    9. покажем поделки

    ну это фастран, можео и лучше ;)
    Ответ написан
    9 комментариев
  • Сhrome extension чтобы можно было разные страницы 1 сайта открывать под разными авторизациями в одном и том же Chrome?

    CDW
    @CDW
    Менеджер проектов\продуктов
    SessionBox, например
    Ответ написан
    Комментировать
  • Как решать проблему недостаточного менеджмента в небольшой команде веб-разработчиков?

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

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

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

    Поймите, почему бэклог задач иногда пустой. Сделать это можно при помощи Канбан-доски. Детально распишите все этапы получения результата для вашего клиента, например:
    1. поиск клиента
    2. переговоры
    3. подготовка ТЗ
    4. согласование ТЗ
    5. контракт
    6. план работ
    7. разработка
    8. ...

    Чем больше этапов вы отметите, тем выше вероятность найти реальную причину отсутствия задач на этапе 7.

    Много срочных, но коротких проектов приведут к авралу на месяц, а потом будете простаивать. Нужно распределять нагрузку таким образом, чтобы работа была всегда. Например, найти долгоиграющие проекты, найдите доп. канал задач (upwork, etc). Нужно формировать пайплайн проектов и выстраивать сроки таким образом, чтобы равномерно распределять нагрузку. Подумайте над маркетингом, где брать больше клинетов, чтобы отбросить невыгодные проекты и взяться за те, где вы сможете нормально зарабатывать.
    Ответ написан
    Комментировать