Антон Коновалов

Как джуниор-разработчику найти работу

Цитата от туда:

Как выход — начал писать на вакансии сеньоров и мидлов со словами «Каким образом попасть к вам джуниором?» и объяснением почему должны взять — как правило обратная связь очень хорошая — зовут в 3 случаях из 4, а также можно заложить фундамент на будущее, если не подходите.

Это битовые операции
Сначала вы 5 (101) сдвигаете на 2 бита вправо (остается 1)
Затем эту единицу сдвигаете на 5 битов влево (получается 32)

00000101 >> 2 = 00000001 (двоич)
00000001 << 5 = 00100000 (двоич) = 32

Помимо прочего, Python является основным языком в Data Science.

Все приведенные ЯП - ЯП общего назначения
питон и руби стоят по-умолчанию в большей части дистрибутивов

Зачем учить - никто не знает

Format String Syntax

name = 'toster'
option1 = f"CREATE TABLE '{name}' ..."
option2 = "CREATE TABLE '{0}' ...".format(name)
option3 = "CREATE TABLE '{name}' ...".format(name='toster')
option4 = "CREATE TABLE '{name}' ...".format(**{'name': 'toster'})

Я расскажу Вам про личный опыт, без претензий на истину в последней инстанции...

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

Для человека который привык работать с реляционными БД, смириться с логикой и вообще с подобными БД - довольно сложно. Для тех, кто работает с реляционными БД профессионально - сделать это ещё сложнее...

Если сравнивать с реляционными БД и с оглядкой на конкретно MySQL - монга идеально вписывается там, где структура данных заранее неизвестна. Тут я хотел привести пример, но не смог придумать ни одного дельного примера, после того как начал плотно работать с PostgreSQL... Давайте попробую из практики. Мы один раз применяли монгу в проекте где есть десятки и сотни тысяч товарных позиций и у каждой из них свой уникальный набор различных свойств. На основе уже имеющихся свойств, "соседних" товаров, контентщику предлагался наиболее вероятный набор параметров, которые нужно заполнить, но в любой момент он мог удалить или добавить любое поле и/или множество значений одного из них, например, "Цвет: черный, серый, фиолетовый". Всё это дело попадало под разные динамические фильтры и далее по цепочке... В то время, насколько я помню ещё не было поддержки JSONB-формата у PostgreSQL, по этому мы остановились на MongoDB. Ну и конечно же, желание "воткнуть ультра новую и модную БД в проект" сыграло свою роль...

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

Безусловно, не редко можно встретить проекты в которых даже в реляционных БД не прописаны, например, внешние ключи и контроля целостности данных как такового нет, но обычно это происходит по следующим причинам:
1. Очень низкая квалификация администратора БД проекта
2. В попытке выжать из базы больше производительности, не найдя других методов оптимизации
3. Данных настолько много, что БД/ключи - начинают "сыпаться", не редко это связано с п.1

Так же, последние тесты показывают, что PostgreSQL почти не уступает MongoDB даже в её родной среде (на уровне данных в формате JSON). А в некоторых аспектах даже превосходит её... Подробности Вы можете увидеть на некоторых конференциях по Postgres (да, на конференциях по MongoDB, Вы вряд ли увидите, как кто-то будет рассказывать, что [их любимая] монга "хуже" некоторых других движков...). Кстати, поддержку формата JSON стандартизировали (наконец-то) на уровне SQL-стандарта (если я не ошибаюсь) и в самом ближайшем будущем, думаю стоит ожидать полноценную поддержку оного в SQL-базах, в т.ч. поддержку в бинарном виде с возможностью индексации данных (кстати, некоторые SQL-базы уже такое умеют).

Моё понимание, ответа на вопрос, "когда действительно стоит использовать MogoDB?" звучит примерно так: Исключительно в тех случаях, когда Вы понимаете, что она станет действительно хорошим решением для поставленной задачи и сейчас и в будущем. В моей практике, таких проектов можно было бы насчитать ничтожно мало, а точнее около нуля, особенно с учётом развития некоторых современных SQL-БД и вообще направления "JSON в SQL" в целом. Но, безусловно такие проекты могут быть и есть (в данном случае, не у меня). Но, тут стоит обратить внимание на крайне важный факт - когда всплывает такой проект, что бы адекватно оценить наиболее оптимальную БД под него - нужно знать как минимум пару-тройку SQL-БД, со всеми их особенностями, достоинствами и недостатками... причем не просто "знать", а хорошо знать, "изнутри". А так же знать все характерные черты монги, а так же её особенности, достоинства и т.д. То есть, если Вы задаётесь вопросом, "а хорошо ли впишется монга в проект N?" и не можете найти на него однозначного ответа, вероятнее всего, что в долгосрочной перспективе, в "проект N" она впишется плохо.

P.S. В заключение, хочу ещё раз напомнить, что "JSON в SQL" - активно развивается... Со всеми вытекающими.

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

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

Как-то так:

def resource_path(relative):

    if hasattr(sys, '_MEIPASS'):
        return os.path.join(sys._MEIPASS, relative)
    else:
        return os.path.join(os.path.abspath("."), relative)

Ну а потом, в процессе инициализации окна:

self.setWindowIcon(QtGui.QIcon(resource_path('file.ico')))
self.tray_icon.setIcon(QtGui.QIcon(resource_path('file.ico')))

Ну и еще, конечно, в spec файл добавить ссылку на картинку в Analysis/binaries:

a = Analysis(['xxx.pyw'],
             pathex=['.'],
             binaries=[('file.ico', '.')],
             datas=[],
             hiddenimports=[],
             hookspath=[],
             runtime_hooks=[],
             excludes=[],
             win_no_prefer_redirects=False,
             win_private_assemblies=False,
             cipher=block_cipher)

slo = dict(zip(k, d))

P.S. Оберните list-ом
temp = list(zip(t, t1))

P.S. И вот эта конструкция:

k = []
for i in a:
    k.append(i)

равносильна:
k = list(a)

Я тут анализировал... Такой себе говноанализ проводил, периодически сканируя если есть возможность и код читаем, т.к. часто бывает его налепят так, что как ни танцуй вокруг него с телефоном - он не считывается из-за очень мелкого размера, крайне хренового качества, или что-то "налазит" на него и т.д.
И пришел я к такому выводу: коды эти сами по себе достаточно полезны и удобны, как механизм/метод передачи определенных объемов информации, но не приживаются они по ряду причин, а именно:
- Многие, если не большинство, людей вообще не шурупают что это за гребаный квадрат и с какой стороны к нему подходить.
Решение: добавлять рядом краткую информацию о том, как его считать и почему это удобно.
- Бесполезный контент! Наверно 80-90% всех кодов несут в себе абсолютно бесполезную хрень, типа урла на какой то убогий сайт, который никому не нужен. Получается, что отсканил код - нашару залил себе говна в телефон в виде, как получается, уже и сюда проникшего спама! Типа вот мы какие современные, хз че его туда зашифровать, а давайте что попало. Люди сканят и: агааа! А вот вам, хлебните говнеца и от нашей компании!))
Решение: публиковать только действительно полезную информацию. Иначе нах.
- Ну и к тому же, самое главное на мой взгляд, это неизвестность! Почему кто-то должен сканить код, не зная вообще нужна ему инфа из него или это будет очередной глоток свежего говнеца но только уже от другой компании!))
Решение: указывать, какая информация зашифрована в коде, чтобы человек понимал будет ли она полезна для него или нет.

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

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