Deerenaros

Ну вообще в университеты требуются и научные сотрудники тоже. Хотя в РФ с этим посложнее, но в целом пара мест на университет бывает. Конкурс, конечно, дикий. Преподавание не требуется, только научная работа под руководством. Минимальный обмен опытом, конечно, будет, но это на уровне раз в год по обещанию. Да и в основном по собственным работам.

А так, да. Прикладные программисты. Попробуй mathematica (или python) и ищи по тегам "машинное обучение" и "нейронные сети", "обработка данных" (data mining). Или попробуй python + GLSL (или какой-нибудь движок и соответствующий язык шейдеров) и там уже играй в геометрию и вычислительную геометрию, поменьше математики, но покрасивее задачи и решения (как правило). Здесь теги примерно такие: "шейдеры", "3д программирование", "GLSL", "HLSL", "opengl", "directx", "(un)biased rendering". Ну и ещё есть физика, метеорология, биология и прочая ересь, где так же нужны программисты и они в основном дробят числа по хитрому. Хотя, что характерно, у нас в стране таким обычно занимаются сами физики, метеорологи, биологи и прочие. Хотя вот в международных компаниях это поставлено чуть правильнее.

Ахтунг, товарищ. Перед тем как сомневаться в профессионализме своих коллег очень советую хотя бы немного сомневаться в собственном. Это как минимум изредка полезно. А теперь ноги в руки и вперёд читать про таблицы, виртуальность и методы. Это не просто полезно, но архиважно. Учитывая, собственно, вопрос.

А вопрос состоял в следующем. Вот у нас есть объекты, друг от друга наследуются, имплементируются и всё круто-прекрасно, но блджад. Зачем они нужны-то? Нет, не агрегация данных, хотя и она тоже. Нет, не агрегация реализации, хотя и она тоже. И нет, нет, не просто потому что. Хотя и это тоже... А вот подумай о такой ситуации. Есть библиотека. Да не важно какая, ну пусть это будет UI/UX. Вот есть абстрактный (!) класс кнопка. Почему абстрактный? Да потому что любая кнопка - это кнопка. Это как бы класс над классом. Кнопка может быть красной, может быть кликабельной, может становится не кликабельной после нажатия, может открывать диалог выбора файлов, а может закрывать приложение к чертям. В общем, много чего может уметь делать кнопка. И вот эту кнопку хочется поставить на формочку. И сделал создатель библиотеки такой прекрасный метод у формы PutAnyButtonHere(Button btn, Point xy). Но... Чёрт, чувак, мы должны передать объект класса Button, а у нас какой-нибудь наследник MyBestButton : BestAbstractLibraryButton, который наследник той самой Button. И у Button декларирован такой прекрасный метод TimeWhenUserClickOnMe(Point xy, AnotherInfo somethinElse), собственно... Получается, что где-то в недрах той самой библиотеки, когда автор прекрасной UI/UX библиотеки вызывает этот самый метод он должен вызвать НАШУ реализацию, а не реализацию BestAbstractLibraryButton. И уж точно не несуществующую реализацию Button (ибо метод там чисто-виртуальный). Идея виртуальных методов изначально именно в том, что есть особая таблица, которая хранит реализации отдельно, объекты отдельно, но когда мы пытаемся вызывать у объекта виртуальный метод происходит такая магия, которую принято называть поздним связыванием.

А ключевые слова это просто для того, чтобы программист читая чужие полотна кода хоть ну немного имел возможность хоть как-то их понять. Что конкретно хотел программист в конкретной ситуации. И, если в Java все методы по дефолту виртуальные и ничерта не понятно из чужих полотен, хотел здесь программист позднее связывание, или это просто агрегация функционала, то в шарпе данной проблемы "как бы нет", язык порой чрезвычайно многословен на, казалось, такие банальности. Что в итоге изредка, но экономит чёртову тучу времени.

Сухой остаток. Если мы вызываем виртуальный метод у объекта класса наследника некоторого супер-класса имея ссылку типа супер-класса, то вызывается реализация метода наследника. Если мы вызываем не виртуальный метод у объекта класса наследника некоторого супер-класса имея ссылку типа супер-класса, то вызывается реализация метода супер-класса. В остальном поведение тривиальное.

Отсебятина. Не понимая данных вещей невозможно говорить, что принципы объектно-ориентированного программирования были усвоены. Советую прочитать "Философия Java" (вообще там Java скорее как язык для примеров, в общем-то ООП оно и в Африке ООП). Ну и пытаться разобраться в точке зрения любого человека, особенно если его компетенция хоть чем-то подтверждена (например, успешным трудоустройством).

Эм? А ничего, что js это клиентская машина, а php - ваша? Другими словами, они могут Атлантическим океаном быть разделены. Можно, конечно, голубей отправлять, но проще воспользоваться websockets или GET/POST запросом (ajax).

Да откуда вы берётесь? В чём проблема продавать? Продавать рекламу, продавать поддержку, о божечки, продавать свободное ПО? Да, доселе коммунизм не построен, приходится пользоваться такими костылями, какими являются деньги. Ну а в целом, вопрос похож на "дайте денег, я успокоюсь". Потому что, если вам интересно развитие индустрии, то вопрос зарплаты как-то отходит на второй план, сам собой. Хороший специалист вряд ли окажется в накладе, а большой вклад в свободные разработки лишь увеличивают его вес. Разбогатеть на open source точно не выйдет, но на безбедную жизнь хватит.

Нейронные сети это довольно старое направление, сугубо математическое, которое получило в последнее время очень мощный пинок под зад благодаря сильно возросшей производительности. Однако, материал по ней очень разношёрстный, очень много дезинформации. И разобраться в этом довольно сложно, особенно учитывая, что она слабо систематизирована и отрасль очень быстро развивается.

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

И так, что мы имеем? Математический аппарат. Цель. И средства. Ну вот, это уже похоже на прогресс. Но чего нет? Адекватной классификации, большого количества хорошего материала, долгой и стабильной учебной практики. Зато вроде есть красивые материалы.

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

Это извечная проблема lenovo, их диски дерьмище полное. Да и вообще на таких вещах все почему-то любят экономить. Варианта два, сглотните и меняйте диск или на гарантию и возвращайте деньги. Сервис центры ремонтируют очень неохотно, поэтому 99% будет возврат.

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

Совет, не скупитесь на чистый ssd и не в коем случае не смотрите в сторону гибридов, тот ещё трешняк.

Во-первых, адекватные люди используют никсы для восстановления данных. Спасибо кривой архитектуре windows. Во-вторых, какие данные и что за файловая система была?

Наконец, если это текст, то элементарная утилита strings на /dev/sdX должна помочь. Хотя и руками придётся поработать, раскидывая данные по полкам, а их будет очень много, очень. А так, обычно хватает форемоста или скальпеля.

Однако, перед тем как начинать, советую сделать изображение диска dd if=/dev/sdX of=/home/username/sdX.image, хоть тут и потребуется много-много памяти. Можно поточно сжать gzip'ом.

UPD.
Забыл написать, что если диск деформирован, то вряд ли что-нибудь поможет, а его использование только навредит. Если за данные можно убить пару миллионов енотов, советую обратится к профессионалам.

Python скорее не язык, а набор спецификаций. C, Java, .Net, да хоть сам Python. Так что выбор и очевиден. И непонятен, собственно, о чём вообще вопрос.

khanacademy.org

Много текста - проку мало.

Во-первых, с чего вы взяли, что конкуренция такая сильная? Откуда числа про 300 миллионов пользователей и обороты в 400 миллионов вечнозелёных (менее доллара на пользователя? потрясающая конверсия!). Вы можете найти инвестора, или уже есть люди, готовые вложиться в проект?

Товарищ, если будет добрый дядька, который даст денег, то деньгами рискует только он. Вы рискуете временем, но точно получите опыт, зарплату себе выписывать - нормальная практика в стартапах (только с инвестором сумму обговорите).

Если его нет, забудьте. Идеи ничего не стоят.

Весьма нескромный вопрос с достаточно тривиальным ответом, но тем не менее, сотней подводных камней.

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

Но. Когда деньги не главное встаёт вопрос об улучшении мира. И если просто взять и улучшить его, хотя бы чуть чуть не так уж и сложно, то не сдохнуть с голода при этом чуточку сложнее. Политика монетизации бывает весьма разнообразной, от модного нынче SaaS или даже PaaS, до весьма консервативной платной круглосуточной технической поддержки. Можно выкладывать в open source не всё, а лишь часть, зарабатывая на остальном, можно дорабатывать по заказу, можно вообще плодить странные модели монетизации, вроде разного рода сертификации (как Oracle с Java, хотя это и не совсем open).

Вообще, стоит заметить, что сегодня практически любая мало мальски серьёзная компания инвестирует в open source. Не потому что это модно, а потому что это удобно, это коммунизм на ровном месте, идеология Маркса и Ленина здесь отрабатывает на все 146%. И на то есть простые причины.

Язык. Когда я прихожу на работу и говорю про linux, я, почти всегда, подразумеваю posix. Когда я работаю и пишу код в vim, собираю по Makefile с помощью gcc, отлаживаю с помощью gdb, а потом отправляю на сервер при помощи git push, я использую готовые, давно разработанные, отлаженные, продукты. После этого, прошивка в виде бинарного кода отправляется на железку, эта железка встаёт на своё место и самолёт летает. Там внутри туча байтов летает туда сюда используя arinc, rs232, ethernet, vga, usb и прочий параллелизм, но самолёт всё ещё летает. Там постоянно происходят ошибки, но CRC-32 легко отлавливает ошибки, а то и исправляет на лету, и самолёт продолжает летать. Свободный софт хорош тем, что им легко задавать стандарты. Один раз написал, триллион раз протестировал, гуглплекс раз использовал.

Не просто так товарищ Столман говорил про GNU, с чего, собственно, всё и началось. Что это не как free beer, но как free speech. Мы говорим, мы общаемся, мы постоянно обмениваемся наработками. Это не остановить, даже если ввести драконовские штрафы и жуткие законы. Но и не надо останавливать, вы лучше оставьте, наконец, общение естественно свободным. Мы общаемся и не просим за это денег. А с голода не умрём, ведь самолёты всё ещё должны летать =)

GetComponent<Rigidbody>().velocity += new Vector(0, jumpPower); // зависит от оси, по которой прыгаем

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

А почему, собственно, и нет?

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

Плумстед не пони точно, но похоже они выводят через мат. ожидание похожую последовательность. То есть по идеи он очень быстрый, но в пределе неточный, то беж неправильный. Посему не вникал.

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

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