• Как уменьшить размеры шаблона сайта?

    @Sashjkeee Куратор тега CSS
    f-e
    А еще можно было бы открыть исходный код и посмотреть как это реализовано.
    Ответ написан
    Комментировать
  • Можно ли работать программистом, но не оценивать сроки?

    Jump
    @Jump
    Системный администратор со стажем.
    Программировать - можно.
    Работать программистом - нет.
    Ответ написан
    3 комментария
  • Каких знаний вполне достаточно по верстке для фриланса?

    zooks
    @zooks
    Frontend
    HTML5 + CSS + Adobe Photoshop + базовые принципы дизайна, типографики, анимации и т.д.
    Вообще хорошим веб-верстальщиком за пару месяцев не стать. Это постоянное совершенствование навыков.
    Ответ написан
    Комментировать
  • Где найти уроки по Ruby on Rails?

    Jeiwan
    @Jeiwan
    www.rusrails.ru (или guides.rubyonrails.org) – этого начинающему хватит на долгое-долгое время. Конкретно по работе с БД — раздел "2. Модели".
    После освоения основ можно переходить к https://www.railstutorial.org/book, https://pragprog.com/book/rails4/agile-web-develop... и ко всему, что выдает гугл по запросам "ruby on rails tutorial", "ruby on rails book" и т. п.
    На сайте https://mkdev.me/ можно скачать бесплатную книгу-путеводитель по разработке на Рельсах. А ещё сайт предлагает услуги менторства, что очень полезно.
    После прохождения пары десятков туториалов и обретения навыка самостоятельной разработки небольших приложений можно записаться на отличный курс – www.thinknetica.com, а после него уже можно будет устраиваться на работу, а там уже... там уже, собственно, всё только и начнется.
    Ответ написан
    2 комментария
  • Кто нибудь пробовал работать во фрилансе после работы?

    Bessome
    @Bessome
    Администратор Linux, Windows. 1С программист
    Надо пробовать. И исключить игры.
    Я вот сажусь фрилансить после 21-00, благо с МСК разница +3 часа. Днем встречи - вечером админинг. И домашние не обижаются, и сна хватает (21-00 + 4 = 01-00). Как-то так спать и ложусь, в 7-00 встаю.
    При этом успеваю - читать, тренить 4 раза в неделю (с 21 до 23).
    Действительно все от человека зависит на самом деле.
    Ответ написан
    Комментировать
  • Какую бесплатную IDE выбрать для bitrix?

    babarun
    @babarun Куратор тега 1С-Битрикс
    Безумный план моих идей в руках больных людей
    Ответ написан
    Комментировать
  • Изменил ns домена, а сайт работает со старого хостинга. В чем может быть проблема?

    @Yago
    Обычно время смены ns-серверов занимает до 72 часов. И запись данных по whois не всегда отображает реальную картину происходящего. Они могут быть прописанными, но еще не до конца переключенными.
    Ответ написан
    1 комментарий
  • Как работать с mailchimp API?

    rdifb0
    @rdifb0
    Программист, реалист
    Качаете отсюда https://bitbucket.org/mailchimp/mailchimp-api-php.
    Берете папку src и подключаете файл Mailchimp.php.
    Про composer читаете отдельную статью habrahabr.ru/post/145946.
    Ответ написан
    1 комментарий
  • Как настроить несколько DKIM на разных smtp серверах?

    SPF softfail - добавьте ipv6-адрес в запись SPF.
    DKIM - возьмите другой селектор, сгенерьте для него свои ключи и разместите соответствующую запись в DNS. Тогда у писем с яндекса будет своя подпись, а у писем с вашего сервера - своя.
    Ответ написан
    1 комментарий
  • Синхронизация с купюроприемником с помощью javascript?

    BiSeTrojanov
    @BiSeTrojanov
    У maratl.exe всем занимается бэнкэнд, а JS общается только с программой maratl, которая, в свою очередь, дёргает купюрник. Если вы хотите из-под JS браузера управлять купюроприёмником (что не лучшая идея), вам надо реализовать API и вебсервер. В C# есть уже написанные модули под купюроприёмники Cashbox. Можете написать вебсервер на C#, который будет дёргать запросы к купюрнику, поданные на этот вебсервер.
    Если будете это реализовывать, не забудьте, что купюроприёмник обладает ещё кучей callback'ов (купюра попала в первый шлюз; купюра потом попала в cashbox; etc).
    Ответ написан
    Комментировать
  • За что разработчик может уважать менеджера?

    80x86
    @80x86
    За то, что это — образ жизни.

    Я попробую изложить тут свой опыт. Думаю, получится ОЧЕНЬ субъективно. Увы.

    Последние три года мне приходится быть этаким Jack Of All Trades (к счастью, без продолжения “master of none“). Я начальник отдела автоматизации учебного процесса довольно большого, но весьма вялого до этой самой автоматизации ВУЗа. Жизнь сложилась так, что кроме этого я занимаюсь веб-разработкой (скорее фрилансом) и координацией нескольких полузакрытых проектов, выросших из аутсорса.

    Соответственно, приходится заниматься административной работой, организационно-координационной и непосредственно разработческой. И рисовать, верстать, копирайтить, тестировать, составлять матмодели, заниматься статистической обработкой и немного паять.

    Это, так сказать, для более глубокого понимания того, почему будет много субъективизма с претензией на объективность.

    До этого, примерно лет пять назад, когда я был чистым разработчиком, на работу менеджеров проекта/команды (да чего уж кривить душой — и на работу любого административного работника) смотрел с презрением, граничащим с этаким public riot. Скорее всего, мне просто не попадалось действительно хороших ПМов, которые бы умели поставить рабочий процесс так, чтобы разработчик понял, что о нём заботятся.

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

    Ещё мне дико не нравилось решать задачу некрасиво, причём это часто выражалось в затягивании сроков. Если мне начальник говорил:

    — Надо срочно сдать! Хватит тянуть резину, что у тебя там, почему нельзя сделать быстрее?

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

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

    Потом было много разных событий, которые во мне окончательно убили веру в то, что менеджер — это друг, товарищ и практически брат. Эти люди не видели проблем коллектива, не хотели для достижения результата жертвовать своими ресурсами или вообще абстрагировались от проблем за мифическими скрамами, процессами, UML и прочей серебряной атрибутикой современного IT.

    А потом я стал начальником.

    Начальником болота, где не слышали про VCS, например. Вообще. И про проектирование.

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

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

    С тех пор многое поменялось в голове: я научился жертвовать перфекционизмом в пользу выполнения поставленной задачи; научился делегировать работу; научился избавлять разработчиков от головной боли и смятений в выборе способа решения задач, выполняя роль своеобразной бритвы Оккама; научился… да научился много чему.

    Теперь я понимаю, что основная работа менеджера — это, в первую очередь, аргументированное и действенное избавление разработчика (исполнителя, подрядчика и т.д.) от психологической «головной боли», которая вызывается тем, что тот выполняет несвойственную ему работу. Собственно, за это разработчик и может уважать менеджера, как человека, профессионально выполняющего свою работу.

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

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