Руслан Ганеев

Чтобы ответить на данный вопрос, надо понять как происходит адресация в TCP/IP сетях.
Когда твой ПК находится например в домашней сети, то область видимости ограничивается этой самой сетью которая была задана маской и адресом сети.
Но тебе надо как-то выйти в сеть интернет чтобы написать вопрос на toster.ru, который в свою очередь находится в другой сети, которая тебе недоступна. Чтобы попасть в нее, надо пересылать твои пакеты через какое-то промежуточное устройство/интерфейс, который знает как доставить твои пакеты именно туда, куда ты хочешь.

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

По отношении твоего вопроса - этого шлюза может и не быть. Тогда ты сможешь работать лишь в текущей сети.

Это простейший пример.

Хорошо знать фреймворк - это понятие довольно субъективное, и каждый человек может в него вкладывать свой смысл. Если Вы планируете искать работу с акцентом на изучаемые фреймворки думаю Вам будет достаточно:
1. Знание общих принципов работы фреймворка (что как устроено внутри), но тут нужно понимать что не стоит изучать каждый класс от корки до корки, т.к. это бессмысленная работа, фреймворки постоянно развиваются и модифицируются. Например, Вы должны знать что такое DI, как оно организовано в фреймворке, и как с ним работать. Но не нужно прям досконально знать код.
2. Чтение документации это хорошо, но практика всегда нужна. Вы не просто должны знать фреймворк по документации, Вы должны иметь опыт работы с ним. Как вариант можете придумать для себя какой-нибудь тестовый проект и реализовать его.
3. Паттерны, архитектурные принципы и т.п. тоже важны, если Вы их знаете - тогда это плюс.
4. СУБД. Для большинства проектов базы используются, поэтому помимо фремворка Вы должны так же хорошо ориентироваться в них, уметь писать сложные запросы, проектировать их и т.п.

Вот сейчас так работаю. Радости нет предела. Преимуществ большая куча.
В этом мне помогла программка астер (aster) - _rutracker.org/forum/viewtopic.php?t=5205496 . Она платная, но можно найти и кряк.

В общем если бы всё было так просто, все бы покупали на семью/офис по одному компьютеру и сидели с разными мониторами :D

Самая лучшая идея :)

Нужны
1. Любой инструментальный ящик.
2. Нормальные кусачки,
3. Нож и набор запасных лезвий
4. Обжимки лучше брать не боковые, тогда со временем они меньше деградируют (точнее ровнее деградируют), что-то типа вот такого расположения dalincom.ru/images/201207/goods_img/3009_P_1343555...
5. Тестер-прозвонку
6. Если работаете с патч панелями - патчевалку, типа https://images-na.ssl-images-amazon.com/images/I/3...
7. Отвертки
8. Изолента и стяжки

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

P.S. Да, выше сказали фонарик - можно посмотреть, если приходится где-то в темном месте обжимать на месте.

www.ibik.ru/ru
www.miniframe.com

Я не являюсь сертифицированным экспертом по технологическим вопросам, а так же не проходил никаких курсов типа такого http://Курсы-по-1С.рф/news/2016-10-17-new-optimiza... . Могу говорить только со стороны своего опыта. Оценить и улучшить работу своей системы без внешнего подрядчика вполне реально.

Есть два простых инструмента:
1) для того, что бы понять все ли в порядке с железом - тести Гилева. Это база данных, которая тестирует ЦП, ОЗУ и ПЗУ, а результаты выдает в сравнении с результатами других пользователей на похожем железе. Если у вас данные хуже, то это явный звоночек, что нужно апгрейдить технику или улучшыть настройку СУБД, если у вас серверная база.
2) замер производительности в режиме отладки. Он многое происходящее в системе не показывает (особенно в модели клиент-сервер), но для оценки тонких мест очень даже хорошо себя показал. Это замечательное подспорье для улучшения своих собственных (не типовых) решений.

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

Для поднятия боевого духа могу поделится тремя случаями из практики.

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

2) Когда-то давно я был разработчиком системы для маленького украинского дистрибутора. Через несколько лет это уже была компания национального масштаба с филиалами во всех областях и они пригласили меня для решения проблемы обмена. У них РБД, которой для сбора данных с филиалов теперь требовалась целая ночь. Практически весь мой код остался за эти года не тронутым и я уже знал где оптимизировать - просто раньше это не имело смысла, так как обмены укладывались в час-два. Согласовал с руководителем проекта и просто выбросил из обмена ненужные данные, подняв скорость сразу в 2-3 раза.

3) Разрабатывал систему он-лайн мониторинга. Обработка главного диспетчера собирала данные и выводила целых 15 минут, что было крайне не "оперативно". С помощью замера производительности выяснил, что большая часть времени уходит на общение с СУБД. тогда я переписал алгоритмы на использование таблиц с предварительно подготовленными данными в оперативной памяти - это позволило ускорится с 15 минут до 4-5. Далее тест Гилева подтвердил своими попугаями, что проблемы в железе. Мы использовали виртуальную машину на украинском хостинге. Арендовали за те же деньги у Хецнера в Германии и сразу получили двойной прирост быстродействия всего - монитор стал отрабатывать за 1-2 минуты. Далее немного подкрутили параметры самой виртуальной машины (поэкспериментировали с различными видами виртуального ЦП, попробовали другие режимы эмуляции) и в результате получили дополнительный небольшой прирост, который позволил обновлять монитор меньше чем за минуту.

Определитесь с ценой за час
Например тысяча рублей за час
Умножьте потраченное время на ставку

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

Здравствуйте, Сергей!

Вашего сканера нет в списке поддерживаемых www.sane-project.org/lists/sane-mfgs-cvs.html#Z-PLUSTEK

Я, в своё время, когда внедрял линукс в школах просто поменялся сканерами с управлением образования :) Им без разницы было, а я получил 100% работающий на линуксе сканер.

Если сканер личный, то проще на авито купить за 500р любой поддерживаемый сканер (большинство HP работают отлично).

есть масса инструментов и сервисов для этого.
google -> load testing
google -> stress testing
гугл -> нагрузочное тестирование

shutdown /r /t 0

Старая байда долгого поиска обновлений. Майкрософт выпустили патч для семерки устраняющий эту проблему. Если раньше поиск мог занимать всю ночь, теперь шуршит быстрее, может и в 30 минут уложиться. Обновление Windows6.1-KB3102810
Ссылка для х86
Ссылка для х64

Была такая же проблема, нашел решение здесь: superuser.com/questions/951960/windows-7-sp1-windo...

Есть такая штука Teensy. На Aliexpress находится.
А вот и руководство как сделать однокнопочный аггрегат.

Если /home отдельно, то нет проблем. При установке Linux Mint не забудьте указать тот же раздел как /home и задать то же имя пользователя и пароль.
Те приложения, в кого в папке /home есть скрытые подпапки, подтянут оттуда настройки. Например у Firefox есть папка .mozilla откуда он возьмёт настройки и восстановит сессию. Если хотите обнулить настройки какой-то программы - удалите её папку перед установкой линукса.
Настройки KDE наверное останутся в соответствующей папке, но для Mate или Cinnamon будут не актуальны.

если не будете форматировать /home, то есесено данные сохранятся.

www.intel.com/content/www/us/en/support/processors...

Какой интересный вопрос... Ну что ж, приступим. У меня как раз вечер свободный выдался, можем и порассуждать.

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

Прошлый век? Не знаю, доля WordPress продолжает расти. Сейчас это почти 27% всего интернета, если мне не изменяет память. Немногим больше четверти всех сайтов в мире. И на пути к одной трети. Вдумайтесь. Осознайте. А еще на WP делают проекты с бюджетами и по 20, и по 50, и 150к условных единиц. И с ежемесячным саппортом в четырех-пятизначных суммах. Все это есть. Рынок огромен.

Смеются над WP-разработчиками? Ну, пусть смеются. А мы тем временем хорошее бабло косим на этом "говнодвижке" (как его называют те, кто высмеивает), работаем в удовольствие, тусим по всяким WP-ивентам, создаем продукты, делаем заказчиков счастливыми, весело тратим заработанное и наслаждаемся жизнью. В общем, все отлично. А смех без причины - признак дурачины (С) детская поговорка.

Да, и обратите внимание на то, кто смеется. Какой-нибудь фрилансер-нищеброд, пытающийся заработать жалкие $400-800 в месяц, сутками колупающий свой кастомный фреймворк и отлавливая в нем стремные баги? Хипстер-рубист? Престарелый ценитель-теоретик C и Java, в 40 лет живущий с матерью? Ну ок. Пусть хохочут. Я не встречал ни одного разработчика высокого класса, независимо от предпочитаемых языков / технологий, который бы смеялся. Потому что опытный человек понимает, что это всего лишь инструмент. Который, к тому же, прекрасно выполняет свои задачи. Так же как Laravel. Как Django. И все остальное.

Есть такие люди, которые Canon vs Nikon, Apple vs Android, Mercedes vs BMW и тд. Holy Warriors они называются, и встречаются в любой жизненной сфере, в любой профессии. Научитесь держать удар и не замечать их существования.

Пришел к выводу, что cms никто не пользуется при создании заказных сайтов, но неужели для каждого сайта пишется свой движок?

Неправильный вывод. Используются, повсеместно. Сплошь и рядом. Вообще, есть 3 подхода:

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

2. Фреймворк. Средне-долго, средне-дорого. Здесь используется готовая основа, необходимые модули, остальное пишется под конкретные задачи. Экономически целесообразно. Это хороший вариант. Но работы бывает много, и велосипеды встречаются, и модули напильником дорабатывать приходится. А если использовать много готовых модулей, то плавно перетекаем в 3й подход.

3. CMS/CMF. Дешевле, быстрее. Тут, если сайт сильно типовой и его можно собрать без особого кодинга - отлично. Но часто и на CMS/CMF бывают весьма объемные и сложные задачи, сильно выходящие за рамки возможностей движка "из коробки" или готовых плагинов. Та же разработка кастомного функционала, доработка напильником сторонних плагинов и тд. В общем, не типовые сайты на базе CMS/CMF делать можно и ничто не мешает это делать. Главное понимать зачем, почему и как правильно. Понимать архитектуру CMS/CMF и как в нее встроиться. Этот вариант сильно выгодный клиенту, особенно если речь о WP, с его огромным рынком специалистов (впрочем, часто сомнительного уровня. Но это везде так, я встречал проекты на Laravel и Yii где от кода тошнило фонтаном).

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

В общем, если WordPress нравится - изучайте его ядро, глубоко и качественно, изучайте глубоко и качественно сам PHP. SQL туда же. Те же фреймворки изучайте, там много интересного и полезного, что можно взять на вооружение. Учитесь решать задачи любой сложности элегантно, быстро, качественно. Учитесь документировать и рефакторить код. Оптимизировать. Использовать best practices. Учитесь создавать качественный продукт, решающий задачи клиента. И вот за это к вам будет стоять очередь, и будут хорошо платить. А не за то, что вы пишете на чистом си плюс плюс. Или на чем-то супер-современном. Enterprise-клиенты вообще такие legacy. А у них больше всего денег, кстати.