Pull to refresh

Comments 123

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

Можно без умножения, деления, дополнительной памяти и экономно по процу. Это калька с Асма на Си.


a=a^b;
b=b^a;
a=a^b;
В задаче требуется использовать только классическую математику (в которую битовые операции, как я понимаю, не входят). В ответе указано, что можно решить используя деление и умножение, но это работать не будет, если одна из переменных равна нулю.
Вот жеж начал читать как обычно с коментариев…
Классика, но уже не актуально. Лет 5 назад тестил на gcc обычный свап через tmp переменную компилится в одну ассемблерную команду. По крайней мере под интеловские процы. Можете поиграться, если есть под рукой gcc :)

Насчёт "экономно по процу" уже можно сильно спорить.


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


mov r0, [a]
xor r0, [b]
mov [a], r0
xor r0, [b]
mov [b], r0
xor r0, [a]
mov [a], r0

Куча дорогих обращений к памяти/кэшу. Зачем?


Если же у нас RISC-архитектура, то одноременный xor и чтение из памяти будут невозможны, придётся использовать два регистра:


mov r0, [a]
mov r1, [b]
xor r0, r1
; mov [a], r0 - тут, конечно, можно было бы записывать в память временные результаты
; mov [b], r1 - но зачем?
xor r1, r0
xor r0, r1
mov [a], r0
mov [b], r1

А теперь вопрос: зачем нужны эти xor, когда можно просто написать так:


mov r0, [a]
mov r1, [b]
mov [a], r1
mov [b], r0

Если же нужно поменять значения в регистрах общего назначения, тогда:


xchg r0, r1

И только если нужно поменять значения в регистрах, а xchg нет, тогда можно выкатить вариант с тремя xor:


xor r0, r1
xor r1, r0
xor r0, r1

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

Спасибо за подробности, я уже давно не в теме. Просто задачка напомнила институтские времена, когда препод спрашивал как поменять два регистра местами, по-моему ещё на Motorola m68k мы работали. Ностальгия.

Это смотря какой проц. На PDP-11 запросто. Да и на x86 при желании можно. Правда там и xchg есть.
На асме меньше всего тактов занимает присвоение (ld, mov, etc в зависимости от асма), а битовые операции и тем более сложение/вычитание (всякие mul и div вообще не должны использоваться и во многих ассемблерах их нет, умножение надо сводить к сложению) ведут к потере производительности. Поэтому тупое решение в лоб — через оперирование доп. регистром или обмен с ячейкой памяти и есть самое эффективное и производительное.
Я про первую задачу ждал подлянок с переполнением ИНТа в ответе, но про них забыли…

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

Если учесть, что переполнение — это уб (по крайней мере в с/с++), то лучше так не делать.

Для вещественных чисел — так точно.
Но в условиях задачи числа небольшие (7, 8), там не нужно универсальный вараинт придумывать.

И да, решение не должно быть частным и должно работать с любыми числами.
Можно так :-)

var a = 26;
var b = 7000;
a = [(-((a — b) — a)), ((a — b) + b)];

b = a[1];
a = a[0];
Все задачи решил сразу, кроме трубочистов, не читал про них. 7 лет работаю в офисе, но своем личном где я один, утром приезжаю как проснусь и уезжаю когда наработался. На работу в офисе дяди с 9 до 18 тоже аллергия
>>И лучшее, что я видел для работы с SQL базами — это HeidiSQL.
После удобного MysqlFront этим нагромождённым недоумением нет желания пользоваться. Максимум загрузить дамп, это он умеет делать быстрее.
2. С компасом дойти мы не скорее всего не сможем, там надо плавать. И не на северный полюс, а на северный магнитный полюс. И даже при всём при этом, точки (именно точки) конечной не будет, т.к. полюс движется в течении суток быстрее чем человек ходит.

Никогда не понимал, как можно работать головой при жаре.

Кондиционеры делают холодно. Электричество сюда уже провели.

Холодно и тут вроде, смысл куда-то ехать?

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

И будет уже не до работы :)

Жара — это в Москве, в Тае — рай, кондеи кругом
Привыкай комментировать практически каждую часть кода, ведь это значительно упростит анализ кода коллегами

Правильная и отличная мысль, можно мне добавить, что комментировать не в стиле зачем (что делает код ясно из самого кода), а в стиле почему. Почему я делаю unshift в array, а не push?
Я сначала комментирую ненужные куски кода, потом через два-три коммита начинаю их потихоньку стирать. Некоторые куски кода оставляю в комментах жить вообще бесконечно, чтобы в будущем не пытаться переписать код к варианту, когда он был оттестирован как неправильный ранее. Даже изменения в коде часто делаю по алгоритму — сначала добавил нужные символы, потому удалил ненужные. (Особенно это касается изменения статических исходных данных, имён таблиц, полей).
Если какой-то код отлажен, приносит пользу и оброс комментариями, то и комментарии тоже копируются вместе с кодом в новый проект.
Если я взял код у кого-то, то даю ссылку на страницу, откуда взято и т.д.
Идея с комментариями ещё может получить дополнительное развитие. Действительно не стоит ими пренебрегать.
Все правильно. По Мартину Фаулеру каждый метод должен называться так, чтобы было понятно что он делает, а в этом случае надобность в комментировании огромного количества кода отпадает.

Комментировать стоит только самые сложные или хитрые места кода или тогда, когда «как-то получилось, но второй раз не воспроизведу» вот для этого случая и пишу комментарий, по крайней мере я =)
Арнольд Шварцнеггер в своей книге «Вспомнить всё» написал, что для достижения успеха надо тренировать не только то что хочется, но и свои слабые места. Для этого, конечно, сначала надо признать, что они есть ;)
2. не однозначна. Можно подумать что человек будет итти до тех пор, пока не придёт назад на старт. Что его остановит на полюсе? С другой стороны может итти до первого водяного припятствия, которое его действительно остановит.
я тоже сразу так подумал, мол, конец пути в его начале.
> Что его остановит на полюсе?
То, что дальше на север идти будет уже нельзя.
И голова очень кружиться будет.

Я тоже вначале поплыл на этом моменте. Но похоже, что компас задаёт не только изначальное направление движения, а вообще всё время пока человек идёт. Т.е это не движение по прямой.

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

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

И вопрос — а почему анонимность
Насчет комментирования — это увеличение времени набора в 1.5-2 раза. лучше давать вместо комментариев вразумительные имена переменным, функциям и прочим сущностям. Числовым константам тоже давать названия.

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


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

Если число заключённых конечно, то последний стоящий заключённый преобразует номера впереди стоящих в одно число (типа new LongInteger(GetBytesFromString("1,2,3,435"))), а дальше каждый следующий декодирует число обратно в список и называет свой номер по порядку.

с решением отлично как говорится ответ написан явно — но сколько останется в живых?

ассемблер — это же не язык, а код — хотя можно спорить чем код отличается от языка.

В бытность молодым я довольно быстро научился читать тест программы с перфокарт.

Но согласен с вами — пишите программы правильно.
с решением отлично как говорится ответ написан явно — но сколько останется в живых?

Останутся живы все, кроме одного.

существует все же ненулевая вероятность, что и первый остнется жив, так как числа произвольны

Обычно всё-таки наихудшие случаи рассматриваются.

ну да — это просто для полноты
Да так говорят — но это размытие термина.
Ассемблер привязан к архитектуре — то есть он машинно-зависим — то есть по сути это мнемоническая кодировка машинных кодов.
Язык программирования — он прежде всего машинно-независим — это средство записи алгоритмов, которая базируется на определенной структуре данных, базовых алгоритмов и интерфейсов.
Для меня это принципиальная разница
Вот с задачей не всё так просто… Число до своего номера он увидит и с какого числа начинается его номер понятно, но если заключенных спрашивают не по порядку, то как он узнает сколько цифр в его числе?
например:
12 23 1 14 16 123 4

сначала спросили последнего, а потом 3-го — какое у него число 1, 11, 114, 1141?
Это был выбор автора, чтобы опубликовать именно анонимно. Мы согласились.
И спасибо за задачу!)
чистый процедурный стиль → функциональный стиль → объектный стиль

Т.е. ООП для вас — вершина эволюции, а функциональщина — лишь шаг к этой вершине?
UFO just landed and posted this here
HeidiSQL — MySQL, MSSQL and PostgreSQL made easy
UFO just landed and posted this here
PostgreSQL

Там весьма условная поддержка. У меня оно постоянно вылетало. Как на минном поле. Сюда не жми, туда не ходи...

Кто из них пойдет умываться?

Надеюсь, оба :)

Я помню это как
анекдот про логику, психологию и философию.
Василия Ивановича послали учиться в Военную академию. По приезде Петька его и спрашивает:
– Ну как, Василий Иванович, чему ты там научился?
– Да много чему, Петька… Вот, например, науки такие: логика, психология, философия…
– Ой, расскажи про науки!
– Ну, как бы тебе объяснить-то… Представь себе, что в сторону бани идут два мужика: один чистый, а другой грязный. Кто из них идет в баню, а кто мимо?
– А черт их знает!
– Эх ты, Петька! В баню пойдет грязный мужик – чистому-то зачем мыться? Вот тебе пример из логики.
– Здорово, Василий Иванович!
– А вот тебе еще задачка: опять идут два мужика: чистый и грязный. Какой из них в баню идет?
– Ну как же, вы же сами сказали – грязный!
– Эээ, нет – подумай, почему он грязный? Потому, что в баню не ходит! Значит, чистый пойдет! Вот это тебе пример из психологии…
– Ну, Василий Иванович, ты даешь!
– А вот еще послушай: идут два мужика…
– Да задрал ты меня своими мужиками!
– А это уже пример из философии…

что? серьезно? никто еще не сказал, что жквери не нужен? :)


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

Просто автор не очень любит фреймворки.

Речь то не о микроконтроллерах.
Выбор языка программирования полностью за вами. Но раз речь у нас идет о веб-разработке, мы рассмотрим выбор между фронтендом и бэкендом.
Скажи мне, как может быть такое, чтобы два человека спускались по одной и той же трубе, и один из них испачкал лицо, а другой — нет?! Неужели ты не понимаешь? Весь этот вопрос — бессмыслица, и если ты потратишь жизнь, отвечая на бессмысленные вопросы, то все твои ответы тоже будут лишены смысла!
Источник

Согласен, ваши задачи бессмысленные.

ИМХО любые тесты/задачи проверяют, то что вы умете/знаете ответы на конкретные тесты и задачи.
К мышлению это очень слабо относиться.
Например я уже знал решения для половины ваших задач.
А то что не знал легко нагуглил.
Сейчас, когда информация находится на кончике пальцев, только на испытательном сроке можно понять — может человек работать или нет.

P.S. Код с комментариями очень трудно читать. Т.к. «все лгут», а уж комментарии особенно.
Вместо кучи комментариев, я бы предпочел хотя бы 50% покрытие unit-тестами. :-)
Обратите внимание как изящно решил проблему Наташи Ростовой автор «Войны и мира» — Пьер Безухов пацифист и пистолета с собой не носит. Всем учиться и учиться у классиков.
Мальчику было 6 лет, его сестрёнке — в два раза меньше. Теперь ему 70 лет — сколько лет сестре?
Не больше 68.
(Почему не больше: она и умереть могла и остаться «вечно молодой».)
(Почему не 67: например, на следующий день ей исполнилось 4, а ему всё ещё было 6, потом прошло ровно 64 года. )
Про КПД и нахождение в офисе — в точку! Работал когда 5/2, то рабочий день выглядел так:
— 9-11 пил кофе и читал новости/хабр/статьи
— 11-12 очень продуктивно работал
— 12-13 работал так себе и ждал обед
— 13-14 обед
— 14 и до конца работал в ожидании «когда же домой»

Основной объем работы делался дома с 22 до 02.00. Потом устроился в компанию, где в офисе надо было появляться на 2 часа, где обсуждались насущные вопросы, шаги, корректировались сроки. Работал часов 5-6 в день с максимальным КПД и объем работ выполнял в разы выше, чем на графике 5/2.

Думаю большое количество разработчиков (не обязательно программисты) поймут меня. Бывает настроения нет, а бывает, что прям распирает.
Насчет ООП и Процедурного стиля. Скорость работы не показатель их различия. Не надо как бабка говорить, что — типа переписали и так получилось, если говоришь то ссылка на репозиторий или какие-то конкретные моменты почему так. А то получается ООП медленное г…, а процедурный стиль фонтан.

Эм, пояснить можете?
Я здесь вижу A=B, B=A: хоть ставьте скобки, хоть нет — переменные там взаимоисключаются.

Осталось учесть переполнения)
Не работает. После вычисления первого выражения А=B, B=B.

Задачи не дают никакого челенджа, да и на самом деле на такие задачи не очень трудно натренироваться.

В Тае хорошо жить, если детей нет. Если есть — совсем не хорошо…
То же самое относится и к работать с 22 до 02, например, как предлагали выше в комментариях.
есть опечатка в ответе на 1ый вопрос:
Первая итерация: А = A + B (7 + 8 = 15), теперь у вас A = 15, B = 8. Вторая итерация: B = A — B (15 — 8 = 7), теперь у нас B = 15, A = 7.
верно так «теперь у нас B = 7, A = 15». а то я подумал, что тут какая-то магия :)

Про оду JQuery. Я давно уже не использую в новых проектах, и ничуть жалею. Обнако, недавно имел удовольствие лицезреть при отладке старого кода, ЧТО под капотом делает метод JQuery.remove для элемента. Я думал это примерно как Node.removeChild, оказалось- там множество циклов и кода при вызовах различных достаточно непростых функций. Весьма любопытно, как такое скажется на прризводительности...

По поводу 6 задачи:
В разработанной вами системе я бы постоянно затаривался товарами со стоимостью <= 24 руб)
С тем же успехом сейчас в большинстве магазинов можно затариваться товарами, стоимостью меньше 1 рубля… Причём даже округления нет — копейки всегда отбрасываются… Вот только товаров таких нет)
Какая чудесная, мотивирующая статья! Она так прекрасно описывает мир ваших радужных фантазий! Приступы кода, интересные задачки, фронт или бэк, #ТАЙ! Не верьте в эту херню.
Есть постоянное изучение фреймворков, языков, библиотек и апи, есть дибилы-заказчики и упыри-аутсорсеры, есть сайты на ___ПЯТЬСОТ МЕГАБАЙТ КОДА И СОТНИ ЧЁРТОВЫХ БИБЛИОТЕК ___, есть надо сделать вчера, есть случайные падения сервера, есть падения гита которых не ожидаешь, есть твои приложения, которые менеджер передумал выпускать.
При условии того, что ты проплаваешь во всём этом дерьме года три а лучше пять ты сможешь уехать в #ТАЙ и писать на аутсорс говнокод не парясь по поводу его качества.
Только это довольно хреновый путь. Потому, что толком программировать ты так и не научишься, зато научишься пихать в любой проект Angular и jQuery, потому что это «ускоряет» разработку.
Программистами не рождаются а становятся. Изучая теорию, читая чужой код, разбираясь в принципах работы сетей, учась администрировать сервера. Тратя на это почти всё своё свободное время. А эта статья о том, что ты избранный и тебя ждёт #ТАЙ, просто маркетинговый буллшит.
Согласна, да и сдался этот #ТАЙ.
+1
Хотите комфорта — не будет развития
А почему нельзя сначала перевезти волка, потом капусту, а потом козу?
потому что пока вы возите волка, коза съест капусту
Так капуста же с волком будет, на другом берегу (уже перевезенная). А коза будет в лодке плыть последней. Как она капусту съест?
На первом шаге вы оставите на берегу козу с капустой
А, теперь въехал :) Спасибо.

Правильно, никак не съест. К этому времени капусту съест волк.

Долго вы плыть собрались, однако)
Пока везешь волка, коза останется с капустой и съест ее)
UFO just landed and posted this here

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

Формулировка задач страдает от недосказанности и неточности. Что такое переменная и «классическая математика»? В математической нотации все значения неизменяемы. Может вы хотели ограничиться простыми арифметическими операторами +-*/ и императивным ЯП?
Что такое идти на северо-восток? У этого понятия есть 2 трактовки: выбрать направление и идти, не сворачивая; и ваш вариант с непрерывной корректировкой. Про магнитный полюс тоже уже написали выше.
Ну вот так и останетесь кодером, который всё, что может — это кодить чётко сформулированные задачи.
UFO just landed and posted this here
Обычно есть контекст, основываясь на котором можно понять, какое решение будет правильным.
Например, фраза
Какая конечная точка будет у вашего путешествия, которое в действительности может продолжаться бесконечно долго, но все же закончится в конкретной точке?
однозначно определяет, что имелось в виду под «идти на северо-восток».

Но я соглашусь, что программист, по-ковбойски интерпретирующий задачу первым пришедшим в голову способом, опасен)
UFO just landed and posted this here
Ну как бы уже не остался.
Задачи «на логику» сами должны быть чёткими и логичными. Потому что без внесения достаточного уровня абстракции они просто не работают. Невозможно идти постоянно на северо-восток: кроме гор и морей мы упрёмся ещё и в дискретность шага. Если корректировки очень редки, то можно вообще никогда не остановиться. Математика это не влезание в голову к спрашивающему, а работа только своей.
Общение с заказчиком это не головоломка, не математическая задача, это совершенно ортогональный навык. Там как раз наоборот требования нелогичны и противоречивы и часто вообще не соотносятся с тем, что действительно удовлетворит потребности. И безполезно лезть в голову к кому-либо, там всё равно ответа нет. Его надо создать.
А «кодер» как раз ищет наиболее простое логичное решение в задаче. Например, (A, B) = (B, A), потому что «в моём языке так можно».
По поводу первой задачи — в классической математике нет операции присваивания. Если ее можно использовать, то почему бы не использовать и множественное "(A,B) = (B,A)"?
UFO just landed and posted this here

решения a=a^b; и a = a + b — это не классическая математика, потому что в математике запрещено повторное присваивание.

Бред не несите. Переменные и в математике переменные.


По вашим суждениям тогда уж и задача бессмысленна.

Повежливей, пожалуйста.


В математике используется одноразовое связывание. Не бывает так, что в начале решения уравнения у вас x = 42, а в середине x = 43.


Задача бессмысленна по своей сути, потому что на высокоуровневых языках пишут a,b = b,a. A на низкоуровневых языках у вас возникает проблема переполнения, чтобы решить которую понадобиться написать еще несколько проверок.

Не бывает так, что в начале решения уравнения у вас x = 42, а в середине x = 43
А что мешает-то? Если вас дальше эта пара «х = 42» не интересует, то никто не заставляет убирать целую букву из списка возможных обозначений. Пишете «теперь, положим x = 43» и чешете дальше
Обратные скидки, да, прикольно. У меня был другой случай, правда как у клиента, когда кто-то умножил прайс поставщика в долларах на курс и накрутил сверху процент фирмы, а когда курс отломился, на 1…
Заказал кучу техники в тот день в том магазине, но магазин нисколечко не сомневаясь отменил все мои заказы)

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

Все так, тай расслабляет.

Последние пять лет каждый год провожу по месяцу в тае, с планами «заодно и поработаю». И каждый раз думаю заранее — «ну теперь точно поработаю». И каждый раз оказывается что работать совершенно невозможно… Что-то я, конечно, делаю — но производительность оставляет желать.
Нет на свете явления страшнее, чем программист с нестандартным и гибким мышлением.
Задачу про трубочистов не поняла, в чем ее сакральный смысл? Есть несколько вариантов после того, как они вылезут из трубы:
1) умываться идут оба (один за компанию)
2) умываться пойдет только грязный
3) умываться пойдет только чистый (почему бы и нет)
4) никто не пойдет умываться (им, может, еще раз в трубу надо будет лезть)
Да нет же, задачка вполне детская и построена на том что первый рефлекторный ответ — «умываться пойдет грязный». Ответ подразумеваемый правильным — «грязный посмотрит на чистого и решит что он тоже чистый, а чистый посмотрит на грязного и пойдет умываться»
Но если у одного лицо испачкано, ему разве об этом не сообщит напарник? Или они просто посмотрят молча друг на друга и пойдут по своим делам? Задание дурацкое, и я бы задумалась об адекватности работадателя, дающего такие «задачки» на собеседовании.
Ну я же и сказал что задачка детская, главное — уловить принцип что умываться идет не тот кто действительно грязный, а тот кто думает что он грязный.
UFO just landed and posted this here

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


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


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

Конечной точкой пути будет северный полюс, но достигаться он будет бесконечно долго.

(1) Это если идти всё медленнее и медленнее, иначе дойдём за конечное время (сделав каким-то образом бесконечное число витков воруг полюса).
(2) Для большинства практических приложений достаточно приблизиться к полюсу на расстояние равное размеру атома.
1. В условии задачи две переменные. Должно работать с любыми числами. Значит, в том числе и с даблами. В общем случае ваше решение не работает.
2. Про то, что надо будет плыть, уже написали. Но скорее всего надо определить, насколько мне можно отклоняться от строгого «северо-восток». Если нельзя, то до ближайшей стены.
3. Недостаточно условий для решения. Например, пойдёт умываться тот, кто всегда умывается после дымохода.

Странные у вас задачи.
«1С битрикс — почему это СПИД в компьютерном эквиваленте» — а где про это почитать?
Я посчитал что в 4 задаче правила действуют для обоих берегов, и следовательно перевозить надо: капуста, волк, коза. Иначе на втором берегу останется кто-то один)
В 2013 году мы вывезли всю нашу команду программистов в Тай. И вы знаете, это было худшее управленческое решений года. Если кто не читал, Тай — это классический способ выстрелить себе в ногу.
Я не утверждаю, что любой проект обречён в Тае на провал, а любой программист — на забвение. Нет. Я просто хочу сказать: из «сработало у меня» не следует «сработает у всех». Автор путает квантор всеобщности с квантором существования.
Название компании-автора статьи и «сложность» приведенных сразу же после заголовка задач, «направленных на определение отдельных немаловажных критериев при отборе специалистов», очень толсто намекают на цель публикации. Ищите лохов недалеких неофитов для выкачивания из них денег обучения?
Задачи-то не самые сложные. Еще в школе нечто подобное решал.
я смогу сделать через HeidiSQL за 1 минуту.
Если Хейди неожиданно не крашнется, что иногда выбешивает.
Sign up to leave a comment.