Андрей

Сам занимаюсь программированием для железок и для ПК в том числе.
Работаю в фирме а так же делаю свои "умные" часы в свободное от работы время. И вижу чего добились другие так же, и вижу что большинство успехов связано либо с железом либо с совмещением железа и софта. Никому не нужен пятсотпервый ещё один "классный архиватор", но все хотят какие нибудь качественные и надёжные гаджеты, предметы, и просто порой качественную мебель которая не пахнет и не токсична (для детей). Все устали от китая, очень устали, не везде есть икея.

Если делать свой бизнес то по-моему только связанный с товаром или электроникой.
Для этого даже не нужно сильно дорогое оборудование, на работе стоит из дорого осциллограф лекрой за 300к, и отладки для ПЛИС за 30к. Но можно вполне спокойно найти usb осцилл за 20к уже приличный, остальное на 10к потянет.

У электроники ещё есть плюсы:
1. Однозначно проще веба
2. Реально сделать что-то самому.
3. Реально растиражирвать и получить прибыль быстро, и вложить её в развитие.
4. Среда в которой крутится твой код не поменяется если сам не сменишь МК/ПЛИС/Распебри/Ардуину. Поэтому сойдёт даже быдлокод - главное чтоб у клиента работало,
5. Поэтому можно быстрее проверить чем веб.

Двоём даже можно сделать такое:
https://www.youtube.com/watch?v=gnjd8yujyKE
https://www.youtube.com/watch?v=J6XkECIYV3I
Мы сделали за три года, тратя в среднем 2 часа в день.

PS. "-малое количество компаний, отрасль слабо развивается" - это плюс, ниша не занята, дерзай! Делай!

GitLab вам в помощь. Вкратце, свой маленький github.
Инструкция для быстрой настройки Debian/Ubuntu

Могу посоветовать неплохую книгу Дэвида Хеффельфингера "Java EE 6 и сервер приложений GlassFish 6". В ней нет привязки к определенной IDE, но на мой взгляд это даже плюс.
книга на амазоне
Есть также русская версия книги.

У меня есть дома книга Шлее по Qt 4.8, она хорошая, но очень простая и краткая. То есть, ее сложно именно читать, я скорее как справочник использую. Сам учился Qt сначала на "Qt 4. Программирование GUI на C++, Жасмин Бланшет, Марк Саммерфилд". Там, конечно. используется уже подотсталое Qt 4.2-4.3, но в остальном книга блеск. По пути можно пару отличных алгоритмов узнать и кучу другого. Эту книгу можно именно открыть и с первой страницы читать. Когда вы ее закроете вы гарантированно будете понимать как работать с Qt.

Совсем мало опыта работы расписано, напишите более подробно, в деталях. Оцените уровень своих знаний в технологиях с которыми приходилось работать, опишите личные качества.
Русский в совершенстве? Я бы Вас не позвал на собеседование только за эту фразу, сами подумайте, чего можно ожидать от человека, который говорит, что он в чем то совершенен — «У меня нет мании величия, великие люди этим не страдают?»
«Могу похвастаться», хммм… мне кажется это не в формате резюме, Вы же не к другу пришли пивка попить.
По поводу фотографии выскажу сугубо свое личное мнение, фотография должна быть, чтобы не терять ни Ваше, ни скажем, мое (так как я постоянно собеседую людей, могу об этом судить) время. По фотографии о человеке можно сказать многое, вот я например, всегда пытаюсь подобрать команду — группа единомышленников, и если скажем у меня работают деловые серьезные ребята, семейные, то вряд ли в такой коллектив вольется татуированный панк с гитарой в кожаной куртке с шипами. Нет… Вы не подумайте, что панк — это плохо или ребята в пиджаках, это хорошо,… нет. Просто команда эффективнее и мне проще подобрать под тех кто есть, нежели выстраивать команду под Вас, поэтому фотография о многом говорит.
Еще как то было резюме с очень, ну очень красивой девушкой 25 лет, а коллектив тогда был исключительно мужской и холостой, ну не было бы работы если бы мы ее взяли, ведь мать природа берет свое.

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

Не ответ на вопрос, но, возможно, решит проблему с другой стороны.
Сам меньше года как перешел с Win 7 на Mac OS. По-началу тоже было непривычно, но позже открыл для себя: Command + [1-4]. В итоге теперь при переходе по папкам использую Command+3. А после нахождения нужной — переключаюсь по необходимости в Command+1 или Command+2.
Сохранение параметров для каждой папки удобно тем, что папка загрузок всегда показывается списком и отсортирована по дате, чтоб свежие файлы были наверху. В папках некоторых проектов — тоже сортировка по времени, фотографии — превью сеткой. Один раз сделал как нужно а потом почти и не вспоминаешь.
Надеюсь, что будет полезно.

Собственно ssh-agent — аналог Pageant из комплекта PuTTY. Использование: генерим на своей машине пару закрытый-открытый ключ, закрытый ключ защищаем паролем при создании. Открытый ключ дописываем в .ssh/authorized_keys на удалённых машинах.

Пробуем логиниться на удалённые машины и наблюдаем, что если раньше надо было ввести password от удалённого юзера, то сейчас надо ввести passphrase от локального закрытого ключа. Когда это надоест, можно воспользоваться Pageant или ssh-agent: запускаем его, просим расшифровать закрытый ключ в память, вводим passphrase, и с тех пор при заходе на удалённые машины passphrase уже не требуется. ssh-agent держит расшифрованный закрытый ключ в памяти и позволяет сторонним процессам использовать его, но не позволяет читать сам ключ.

Если у ssh-agent указана команда (x-session-manager в нашем случае), эта команда запускается подпроцессом ssh-agent'а, и ssh-agent завершится вместе с этим дочерним процессом. Похоже, ssh-agent навешивают на иксовые сессии именно таким образом.

P. S. X11 Forwarding — это другая фича ssh. X11 клиенты авторизуются посредством волшебного кукиса (.Xauthority), к которому обычно имеют доступ только локальные процессы, запущенные тем же юзером. Чтобы кукис не утекал на лево, как мера безопасности, ssh на удалённой машине использует другой кукис и после проверки подменяет его в протоколе на локальный кукис.

Насколько ваше образование было далеко от IT?
Математика, дискретная в частности? Это некий базис для архитектора. Потом пошли best practice, шаблоны и отдельные, хорошо изученные случаи типа клиент-сервер. Понимание приходит с опытом — пока что нет объединяющей теории, которая перечислила и оценила варианты дизайна. Если вы поняли Project Managment то должны быть знакомы с WBS и то как строиться план работ. В архитектуре примерно также — берем большую задачу и начинаем ее разделять на «красивые» куски. используя какие-то шаблоны. И так до тех пор пока минимальными кирпичиками будут понятные, читай шаблонные, задачи.
Базы данных базируются на RDBMS

Судя по списку вы работает, хотя скорее пытаетесь, работать ПМ-ом или бизнес-аналистом в студии веб-дизайна?
Если так что архитектура приложений для вас MVC, сетевая — клиент-сервер, базы данных для вас вторичны. ибо закрыты ORM фреймворка

Data Communication and Networking (основной упор, был на типы сетей, протоколы, совсем немного про роутеры. но ничего не было про cloud, например).

Я не вижу смысла разработчику углубляться в сети. Однако, по опыту общения с разработчиками скажу: вы ОБЯЗАНЫ прекрасно понимать работу стека TCP/IP и в первую очередь самого протокола TCP, который на самом деле имеет массу нюансов. Но при этом то, каким образом роутеры осуществляют доставку пакета, вам едва ли потребуется, этим займутся другие люди.
Я давно сбился со счета, сколько раз мне доводилось анализировать дампы пакетов тормозящего сетевого приложения и к примеру объяснять разработчику, почему в Москве оно летает, а во Владивостоке страшно тормозит при слабо нагруженных каналах связи.
Упомянутый выше CCNA — это здорово в качестве базы. Но стоит попутно углубиться в работу TCP на конкретных конечных системах.

Есть webkit'ы без всего — Uzbl/Midori/Luakit/Surf, первые два точно работали на Duron 800, 128 Mb.
Или Firefox 3.x.
Движок рендринга переписывать никто не будет.

Во-первых, открывать поля класса для публичного доступа — это почти всегда плохая идея.
Во-вторых, очень важно, чтобы API был лаконичным и кратким. Стороннему разработчику, который будет пользоваться вашим классом, не нужно видеть больше методов, чем может понадобиться по смыслу задачи (не перегружайте людей информацией и не раскрывайте деталей своей реализации).
Поэтому методы стоит определять как private по умолчанию. Если выяснится, что метод может потребоваться (или его поведение может уточниться) в потомке, то делайте его protected.

Делать публичными стоит только те методы, которые соответствуют смысловой абстракции.

Как сказали выше, private нужно использовать для тех переменных, которые не нужны будут наследникам класса для использования в явном виде.
Я, например, все переменные делают private и только при острой необходимости перевожу их в protected. Но чаще я делаю просто protected геттеры и сеттеры для этой переменной, т.к. как может возникнуть необходимость контролировать доступ к ней и из дочерних классов.
К тому же не забывайте, что в разных языках protected ведет себя по-разному. К примеру, в C++ protected позволяет дочерним классам иметь доступ к переменной, а в Java — дочерним классам, а так же всем остальным классам, находящимся в этом же пакете.

rescuetime.com