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

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

Стал замечать, что разработчиков сайтов на 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. А у них больше всего денег, кстати.

Линкедин это по большей части для западного рынка, когда вы уже поработали в нескольких неплохих компаниях, написали у себя в истории крутые должности с красивыми и офигенными описаниями и параллельно со всем этим обмазались всякими "коннекшенами" со всех тех же мест где вы работали (или с кем пиво на конференции пили). В общем такой себе Circle Jerk, на котором вас в основном будут находить ушлые HR, отправляющие слегка измененную копипасту с описанием вакансии.

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

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

Для Linux:

using System;
using System.Diagnostics;
using System.IO;

namespace Test
{
	class MainClass
	{
		public static void Main (string[] args)
		{          
			string result = LinuxTerminal.GetOutput("find /sys/class/input -maxdepth 1  -name \"mouse*\"|wc -l");
			int outputValue = int.Parse (result);
			Console.WriteLine (outputValue);
			Console.ReadKey ();
		}
	}
}

using System;
using System.Diagnostics;

namespace Test
{
	public static class LinuxTerminal
	{
		private const string TerminalPath = "/bin/bash";

		public static void ExecuteCommand(string command)
		{
			var proc = new Process();
			proc.StartInfo.FileName = TerminalPath;
			proc.StartInfo.Arguments = "-c \" " + command + " \"";
			proc.StartInfo.UseShellExecute = false;
			proc.Start();
		}

		public static int GetExitCode(string command)
		{
			var proc = new Process();
			proc.StartInfo.FileName = TerminalPath;
			proc.StartInfo.Arguments = "-c \" " + command + " \"";
			proc.StartInfo.UseShellExecute = false;
			proc.StartInfo.RedirectStandardOutput = true;
			proc.Start();
			proc.WaitForExit();
			return proc.ExitCode;
		}

		public static string GetOutput(string command)
		{
			var proc = new Process();
			proc.StartInfo.FileName = TerminalPath;
			proc.StartInfo.Arguments = "-c \" " + command + " \"";
			proc.StartInfo.UseShellExecute = false;
			proc.StartInfo.RedirectStandardOutput = true;
			proc.Start();
			proc.WaitForExit();
			return proc.StandardOutput.ReadToEnd();
		}
	}
}

Из под винды так работает запуск программы и получение ExitCode

using System.Diagnostics;

namespace ProcessStart
{
    public static class CommandLine
    {
        public static int ExecuteCommand(string applicationPath, string command = "")
        {
            var proc = new Process();
            proc.StartInfo.FileName = applicationPath;
            proc.StartInfo.Arguments = command;
            proc.StartInfo.UseShellExecute = false;
            proc.StartInfo.CreateNoWindow = true;
            proc.StartInfo.WindowStyle = ProcessWindowStyle.Hidden;
            proc.Start();
            proc.WaitForExit();
            return proc.ExitCode;
        }
    }
}

using System;
using System.IO;

namespace ProcessStart
{
    class Program
    {
        private static Program _program;

        static void Main(string[] args)
        {
            _program = new Program();
            _program.Run();
        }

        private void Run()
        {
            const string ProgramName = "ReturnRandomNumber.exe";
            string appName = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, ProgramName);

            int exitCode = CommandLine.ExecuteCommand(appName); 
            Console.WriteLine(exitCode.ToString());

            Console.ReadKey();
        }
    }
}

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

Собирай в /tmp

В нормальной версии убунты в системных путях нет пробелов и кириллицы

Также не рекоммендую делать make install

С точки зрения программиста, я-бы изучил дополнительно следующие вещи:

1) Конвеер процессора
2) Кеш память
3) Шина данных
4) Многопоточность процессора (у AMD сейчас одна, у Intel другая)
5) Ускоряющие инструкции, типа SSE

Больше ничего, если не заниматься вычислениями на видеокарте, не нужно, по большому счету.

Sandisk ULTRA II, Samsung 850

На данный момент беру эти, в основном. Проблем не было.

Раньше хорошие были Crucial M550, M500, M4, Plextor M5.

Указывать Сокет напрямую нельзя (AMD обидется). Но можно указать архитектуру, чтобы ARM вместо x64 не подсовывали. Количество ядер, частота, объём кэша, TDP(по теплопакету отсекаем AMD-печки). Причём, лучше не строго указывать, а как минимальное значение. Т.е. если предложат что-то лучше, то зачем от этого отказываться?
С видеокартой аналогично. Если нужен именно GeForce, то требуем поддержку CUDA.

А вообще, когда хочется обжулить закон, то этим должен заниматься продавец, а не покупатель. Т.е. связываетесь с конкретным поставщиком и пусть он уже ломает голову над составлением текста заказа. чтобы выиграть торги. Вам даже откат за это полагается.) Вообще, будто первый раз в России живёте.