• Нужно ли провинциальное высшее IT образование?

    @melang
    Автор, ты спрашиваешь у поколения (30+ лет), в котором почти все из "интеллигентных" семей получили вышку, иначе это был в то время просто неадекват. Естественно, признаваться другим и себе, что за 5 лет никаких полезных знаний не было получено, большинство не будет. Я ушла с 5 курса престижного московского вуза и очень рада, что доучилась почти до конца - теперь я наверняка знаю, что там ничему не учат и байки про "специальные предметы начнутся на старших курсах" - это байки. Вузы для программистов - это бизнес на родителях, вот и все. Аргументы любителей вузов:

    - некие большие компании, куда закрыт ход без корочки - если ты нормальный специалист, ты сам выбираешь, где тебе работать, можешь вообще делать свои продукты/плагины/игры/уроки и продавать, получая пассивный доход
    - переезд за границу - см. пункт 1, если ты нужен компании, тебя перевезут. Только часто бывает выгоднее работать по удаленке
    - знания - на деле это черчение, матан, физика, культурология, физра, экономика, экология, философия и какой-нибудь С# и SQL на уровне, который 10-летний ребенок освоит за 2 недели (без преувеличения).
    - "учит учиться" - меня скорее вуз научил пить и списывать, кстати рекомендую сдавать экзамены по билетам с микронаушником в ухе и другом на проводе, острые ощущения
    Ответ написан
    1 комментарий
  • Что делает этот кусок кода?

    @nirvimel
    Код побайтово записывает 64-битное число в bytearray размером в 8 байт.
    Автор этого (трехколесного) велосипеда, видимо, не дочитал справочник по Python до главы 7, в которой описывается модуль struct, решающий именно эту задачу.
    Из-за таких велосипедов (с циклами для записи одного числа) и рождаются легенды о том, что Python тормозной язык.
    Ответ написан
    Комментировать
  • Все ли на самом деле плохо с Python на удаленке?

    Guest007
    @Guest007
    Django, Python, Linux и всё такое...
    Как раз в преддверии 40-летия понял, что ни сил, ни желания админить в моём маленьком городке уже нет. Но и трое детей не давали возможности просто махнуть рукой и не напрягаться по жизни.
    Было:
    • желание удалёнки/фриланса
    • неудачный прошлый опыт
    • неплохой уровень администрирования
    • кое какие аналитические способности
    • опыт с несколькими языками программирования

    Предпочтение - Python/Django.
    Написал резюме по правилам, разослал везде, мониторил разные группы/форумы.
    Взяли в один проект (на полгода). Понял, что выдавал желаемое за действительное и мой уровень был, как сейчас говорят "джун". Но Джун - не приговор. Просто тратил на решение задач больше времени. В том числе и за счёт личного.
    Потом снова искал. Попал в стартап прям в самом его начале. За полтора года поднял уровень. Потом потыркался по всяким upwork и вебстудиям, пока опять не нашёл интересный стратап.
    В общем - не бояться и не комплексовать. "Ищите и обрящете" :-)

    По моему опыту общения с начинающими сейчас, с теми, кто самоназывается "Джун" - проблема ребят в том, что ни мыслить, ни искать решения особо не умеют. Доходило до того, что взятый в проект JS-React "специалист" не мог ни проанализировать ТЗ, ни выдать алгоритм действий по его реализации. Даже без подробностей. Я, питонист, тыкал его в выдачу гугла по вопросам, которые у него возникали.
    Или, вот, парень в ВК спросил что-то в группе по какой-то задаче. Я подсказал. На свою голову :-) Еле потом отвязался. Вопросов у него было много, но на вопросы по Питону, не смотря на призывы подумать и поискать, в итоге приходилось тыкать его вы первые позиции выдачи Гугла. Т.е. человек, желающий стать (точнее - зарабатывать) программистом и штудировавший Лутца (по-моему) просто не мог загуглить. Вообще.

    Ну, это так, немного опыта, немного наболевшего :-)
    Ответ написан
    2 комментария
  • Как уйти с распутья технологий?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Leo698
    @Leo698
    php developer
    Берите дешевый VDS и разворачивайте там что угодно)
    Ответ написан
    Комментировать
  • Как установить simpleguics2pygame на python 3.4 версии?

    Для Windows нужно устанавливать из бинарных файлов: https://pypi.python.org/pypi/SimpleGUICS2Pygame
    Ответ написан
    Комментировать
  • Реально ли восстановить BIOS в случае, если его нет?

    Spetros
    @Spetros
    IT-шник
    Способ решения проблемы "Boot Menu App Menu" на самсунге.
    www.youtube.com/watch?v=eptpyMbnY4o
    Ответ написан
    1 комментарий
  • Реально ли восстановить BIOS в случае, если его нет?

    icelaba
    @icelaba
    Знаю и умею всё
    Походу ситуция такая же forum.notebookreview.com/samsung/704229-stuck-boot...
    включен fastboot и снесена родная винда и разделы с диска :-)

    Народ что только не пробовал но закончилось все отправкой в сервис
    Ответ написан
  • Реально ли восстановить BIOS в случае, если его нет?

    icelaba
    @icelaba
    Знаю и умею всё
    может я недогоняю но как rm -r /dev могла стереть bios?
    Ответ написан
    3 комментария
  • Как можно передать ссылку на экземпляр класса в другие модули, чтобы взаимодействовать с ним?

    @hsc
    full stack python back-end developer
    Не думайте о потоках как об объектах, потому что они ими не являются. Поток — это нить выполнения, которая во время инициализации принимает функцию, которую будет выполнять. После инициализации — это отдельный мини-процесс. Вызвать метод потока невозможно: у него их попросту нет. Можно вызвать метод дескриптора (объекта, который управляет потоком) но не самого потока. Отличием потоков от процессов является то, что потоки разделяют адресное пространство с процессом, который их породил. Это значит, что каждый поток имеет доступ к данным процесса и других потоков.

    Теперь о вариантах решения. Я их вижу несколько:
    1. Перед запуском потока создать proxy-объект, экземпляр класса, который будет описывать подходящую для вас структуру данных. В зависимости от задачи, может быть полезным посмотреть на Queue, он из коробки потоко-безопасен. После этого просто передать ссылку на этот объект в конструктор потока и общаться через него. Поток пишет в этот объект - django читает из него, и наоборот. Модель очереди для таких задач подходит как нельзя лучше, потому как нельзя гарантировать то, что поток подхватит задачу сразу по ее появлению, и другая задача не затрет предыдущую. Создавать proxy-объект нужно в такой точке, из которой выполнение процесса родителя не выйдет до остановки потока, иначе Вы рискуете потерять контроль над потоком или ловить "странные" ошибки.

    2: Если есть необходимость ставить перед потоком разные задачи может быть разумно вынести их хранение во внешние службы, например redis. Он очень быстрый и существенного оверхед даже на малинке не создаст. Общаться с ним можно через этот пакет. Если хотите сэкономить на tcp-трафике - запускайте redis на unix-сокете.
    Этот вариант потенциально избавит Вас от головной боли с синхронизацией задач.

    3: Если есть возможность и памяти хватает больше чем на 1 поток - RQ. Это — легкий менеджер очереди задач для python. По сути, то, что Вы и пытаетесь реализовать.
    Ответ написан
    7 комментариев