Ярослав

Никуда ваша память не делась. Прочитать подробнее о том, что конкретно происходит, можно здесь - linuxatemyram.ru (оригинал)

sudo apt-add-repository ppa:jon-severinsson/ffmpeg 
sudo apt-get update
sudo apt-get install ffmpeg

b'123' - это массив байт

out.decode('utf-8').split("\n")

У шаблонного класса методы размещаются в заголовке. Переносите.

Больше велосипедов в домашних проектах.

Например, попробуйте на C++ написать свой HTTP-сервер. Который бы был полностью асинхронен. Чтобы можно было взять вашу библиотеку, создать экземпляр сервера, указать ему порт, навешать хэндлеров на обработку запросов, которым бы передавались объекты для управления запросом (в том числе считывание/запись данных, сервер не должен делать этого сам, приложение должно) и от которого не требовалось бы произвести обработку запроса тут же на месте, а когда ему захочется в будущем.

Я постараюсь подключить философию, примеры и "как если бы я говорил в баре с вами".

ЯП - это инструмент. Инструмент всегда взаимодействует с объектом и со средой. Соответственно, вам точно нужно что-то знать про объект и уметь пользоваться инструментом внутри среды, а это потащит дополнительные знания, назовем их "естественными" зависимостями. Насколько глубоко их нужно знать? Тут ответа не бывает: настолько, насколько нужно и хочется. Тут важен баланс и акцент. Если нет строгих параметров на уровне разума, нужно верить интуиции, потому что больше нечему. Для JS-программиста JSON/jQuery/AJAX - это естественные зависимости, их в любом случае не получится обойти. Даю зуб, что вам хватит вечера и немного гугла, чтобы стать чуть ли не LIKE A PRO в этом. Это все форматы хранения данных, либы, парадигмы. Это примерно как прочитать состав у шоколадки по сложности и входному порогу. Скорее всего, вас пугают сложные слова. Примерно как сказать "НАПРАВЛЕННЫЙ АЦИКЛИЧЕСКИЙ ГРАФ", и вы сразу знаете теорию графов, хотя с практической точки зрения суть настолько элементарна, что аж страшно, а вы будете долго прокрастинировать и искать что попроще.

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

Вы можете просто верстать (html/css) и игнорировать программирование в целом. Но естественная среда противится: вы уже (!) пишете на декларативном языке, неплохо было бы узнать об этом подробнее (о языках или даже о типизации), тем более, что крайне близко к вам находится интереснейший язык js, а там моментально вылезут проблемы связывания html и js, разные подходы к этому, целые парадигмы и фреймворки; и вот вам выпадает интересная задача по анимированию svg, вы курите мануал по нужной либе, читаете что-то про reflow/repaint, внезапно узнаете что-нибудь про селекторы. И через какое-то время, будучи все тем же верстальщиком, вы видите архитектурный косяк дизайна, который очень неудобно укладывается в используемые технологии, предлагаете его пофиксить и спасаете команду от факапа через месяц, когда какой-нибудь транзишн наложится на какой-нибудь position: fixed и еще и в Safari упадет анимация и только там, а тут и новая тудушка: "Переделать, нафиг, всю шапку, чтобы ок было". Что-то изменилось в мышлении и картина стала полнее. ВНЕЗАПНО вы уже и инженер, можно сказать, ЗП растет, все дела, рутины меньше стало.

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

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

Так вот, теперь у нас есть естественные зависимости, инжиниринг и баланс между порогами. А не php/jquery/html/css.

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

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

А теперь, собственно, выводы:

1) Вакансий крутых много, надо пробовать. Нужно только отличать близкие и необходимые естественные зависимости от мастера на все руки. Я считаю, что мастером на все руки нужно поработать хоть однажды, чтобы просто понять, почему это плохо. Но зависимости будут всегда, и это норма. Вы перечислили слишком радикально, конечно.
2) Себя пилить под вакансию не нужно. Нужно просто идти туда, где интересно, всегда стараться быть инженером и не убить в себе искусство (то есть не бояться делать так, как кажется правильно, чтобы либо убедиться в правоте, либо ошибиться и стать круче).
3) Не нужно думать в стиле "а что если завтра рубионреилс развалится, комьюнити разойдется, вакансий не будет, что я буду делать". Вы же инженер. У вас опыт в проектировании IT-систем, перейти на что-то смежное, если будет понятно, что технология умирает, не составит труда.
4) По естественным зависимостям нужно двигаться по мере интереса, вы станете от этого только лучше.

Это, конечно, если вам действительно все это интересно. Все это области, очень близкие к искусству, и тут надо любить все это делать.

Никакие.

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

Вообще, в области server / desktop / mobile очень сложно уйти далеко без, как минимум, следующего:

• Объектно-ориентированное программирование и проектирование — ведь код не должен быть говном
  
• Параллельное программирование — ведь делать нужно много и быстро, а у нас уже 10 лет как многоядерные машины есть
  
• Сети — ведь нельзя жить без интернета
  
• Базы данных — ведь данные надо где-то хранить, и хранить надёжно
  

hardware не комментирую, но там ещё хардкорнее.

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

1. Бумага - вещь достаточно тяжелая. Стопка книг создает большое давление на нижние книги, что вызывает деформацию (слипание страниц, отпечатки текста на слипшихся страницах. Вплоть до того, что при попытке разъединить, страницы будут порваны).
2. Горизонтальное хранение позволяет легко извлечь любую книгу и вставить ее назад. Давление у каждой книги свое, вы зря беспокоитесь про корешок - его достаточно, чтобы удержать страницы одной книги.
3. Проще делать полки под горизонтальное хранение, чем под вертикальное.

Часто применяется для:

1. Локальные приложения и утилиты командной строки

• Сборщики и трансляторы
  
• Пакетная обработка и сценарии отложенной обработки
  
• Скрипты, CLI (интерфейсы командной строки)
  
• Генерация документации, отложенное формирование отчетов
  
• Сценарии тестирования для других систем
  

2. Серверы

• Серверы веб-приложений и SPA
  
• Серверы и API для мобильных приложений
  
• Любые другие веб-API (RPC, JSON, REST)
  
• Серверы сообщений и трансляция событий (чаты, игры, интерактив)
  
• Заплаты на уже готовые системы, написанные на других языках, для реализации вебсокетов, SSE, лонг-пулинга и т.д., т.е. для затыкания дыр, для решения проблем в узких местах уже работающих систем.
  

3. Клиенты

• Оконные приложения (nw.js, node-webkit)
  
• Кравлеры, парсеры и сбор данных
  

4. Железо

• Программирование микроконтроллеров (arduino, espruino, tessel)
  
• Промышленная автоматизация
  

Редко применяется (но подходит) для:

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

И плохо подходит:

• Вычисления и моделирование, со скоростью математических операций нода и JS, как не типизированный язык, не дают хороших показателей
  
• Научные приложения (по тем же причинам)
  

Список хранит ссылки на переменные в памяти, а значит список длиной N в 32-х битных системах будет иметь размер (2*2)*N, а в 64-х битных (4*2)*N

>>> from sys import getsizeof

>>> l = list()
>>> print getsizeof(l)
32 (в 32 битной системе)
64 (в 64 битной системе)

Значит искомая величина 32 + (2*2)*N (в 32 битной системе), 64 + (4*2)*N (в 64 битной системе), где N - длина списка.
Но список хранит указатели, а значит место займут еще и сами данные. В вашем случае данные имеют тип integer

>>> from sys import getsizeof as gs
>>> a = int()
>>> print gs(a)
12 (в 32 битной системе)
24 (в 64 битной системе)

Значит памяти всего израсходуется
32 + (2*2)*N + N*12 (в 32 битной системе)
64 + (4*2)*N + N*24 (в 64 битной системе)

Для списка из 7млн чисел имеем:
32 + (2*2)*7000000 + 7000000*12 = 112000032 байт = 109375 Кбайт = 106.8 Мбайт
64 + (4*2)*7000000 + 7000000*24 = 224000064 байт = 218750 Кбайт = 213.6 Мбайт

Есть хитрый вариант, подходит для вложенных объектов:

>>> x = [u'привет мир']
>>> x
[u'\u043f\u0440\u0438\u0432\u0435\u0442 \u043c\u0438\u0440']
>>> print str(x).decode('unicode-escape')
[u'привет мир']

print 'Привет,', name  # python < 3
print('Привет,', name)  # python >= 3