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

Мысль номер один, если компания например внутри больше пишет на c++/java и например хантит таких разработчиков, то компании не выгодно ориентироваться при разработке задач пишущих на более медленных языках.

Далее, действительно разработчики задач, периодически сталкиваются с такой проблемой, то что решение за квадрат на c++ работает например почти как решение за n log n на python. Да, обычно удается решить эти проблемы, небольшой корректировкой условия задачи, и придумыванием качественных тестов. Но не всегда.

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

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

И последнее, отвечая на предложение с вашей колокольни. Это к сожалению не сработает, потому что бывают решения у которых не детерминированная сложность. Решения которые например работают за отведенное время но оптимизируют результат, такие как банальный перебор, метод отжига, генетические алгоритмы, и.т.д. И эти решения тоже считаются решениями.
Если мы будем пытаться вычислять сложность используемого в решении алгоритма, то тут и ошибиться просто, и что с такими решениями делать не понятно, и в итоге из строгой системы судейства получим систему из костылей (имхо).
StopKran
+3
У меня на собеседовании как-то раз был примерно такой случай (обсуждали моё тестовое задание):
-Скажите, а вот тот код который вы написали, вы не хотите его отрефакторить?
-Нет
-Но как же, вы же просто скопипастили эти две строчки 4 раза!
-Да
-И вы не хотите вынести их в процедуру!?
-Нет, мне же не придётся поддерживать этот код.
-Но это же не красиво!
-Этот код идеально выполняет поставленные задачи. В связи с отсутствием развития этого кода в будущем, не считаю целесообразным выполнять пустую работу, и стремиться к какой-то мифической красоте.
-Но как же, но это же не правильно (и дальше паника в глазах собеседующего меня тим лида)
StopKran
0
Теперь ждём пересмотренное дополненное руководство по Grunt для начинающих, 3-е издание.
StopKran
+1
А есть какие-нибудь ограничения по времени, и по размеру входных данных?
StopKran
0
А почему Scala нельзя, если не секрет?
StopKran
0
Работаю в бизнесе связанном со связью. На самом деле там не подставные паспорта, а просто придуманные паспортные данные. Более того придумываются эти паспортные данные в массовом количестве, по скольку есть «планы», за невыполнение которых взимается штраф, и все недопроданные симки активируются, якобы они были проданы, и регистрируются на фейковые лица. Операторы ни как не проверяют эти паспорта.
StopKran
+2
Предлагаю тогда вообще RenderCoin, с соответствующими изменениями =)
StopKran
0
Теплораспределительную крышку уже снимал, это да. Хочется именно вот ту красоту, что на картинке. Ладно, попробую на досуге ещё ножичком поковырять 8-)
StopKran
+2
Извините за оффтоп: но можно ли как-нибудь сломать процессор, так же как на первой фотке, что бы увидеть кристалл?
StopKran
+2
1. Можно скомпрометировать первые узлы в дереве, то есть узлы котором пользователь непосредственно передал информацию. Тогда если этих узла два, это полнейший фейл. Скомпрометировать их просто. Если их много, то смысла строить дерево уже нет. Передали информацию пятидесяти допустим пользователям, и с них же и собрали. Дерево в данном случае не увеличит криптостойкость.

2. Это катастрофически не эффективно в плане скорости. Потому что скорость передачи данных ограничивается скоростью узла в «дереве» с минимальной скоростью.

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

P.S. Криптографией не занимаюсь, по этому где-то могу ошибаться. Но пока я не вижу никаких преимуществ такого способа «шифрования». Перед тем же tor вообще никаких преимуществ.
StopKran
+5
Есть смысл приходить, если ни разу не писал на swift, и даже под мобилки не девелопил?
StopKran
–4
Говнокод забыли
StopKran
0
Прикольно. А версия ядра какая там?
StopKran
+1
Мне больше нравится такой вариант: habrastorage.org/files/4d2/52b/dce/4d252bdce02c4ab783792261772fb579.png
StopKran
0
>В Опере я просто выделяю текст, а в Хроме надо запоминать всю эту магию
Вы говорите как Стив Джобс, честное слово =)
StopKran
+1
Не привычно, но вообще мне нравится. Давно пора.
Ещё неплохо было бы, если бы заредизайнили определения уровня комментария. Считать эти точечки, уж очень геморойно. Раньше almalexa делал плагин для stylish, который редизайнил хабр. Вот там просто у каждого комментария слева стояла крохотная циферка — номер уровня. Было дико удобно.
Комментарий из публикации, перенесённой в черновики.
StopKran
0
У самой системы в лецензионном соглашении написано, что использоваться она может только на компьютерах фирмы Apple.
И это же кстати не обозначает, что та сумма за которую вы покупаете систему, есть её полная стоимость. Так как ставить её разрешается только на маки, то когда вы покупаете мак, вы уже уплачиваете часть от стоимости системы.

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

А ещё вы не репрезентативны =)
StopKran
+2
То же самое что вы предлагаете вполне себе делается так: покупается какой-нибудь midi контроллер с клавиатурой и крутилками, и аналоговый синтезаторный модуль с управлением по миди, и в промежуток ещё вставляем компьютер, вот вам и аналоговый синтезатор с цифровым управлением. Но судя по моим коротким гуглениям, таких аналоговых синтезаторных модулей катастрофически мало, так что может быть оно и будет востребованно. Не знаю. Мне вообще сложно оценивать, потому что я гитарист =) В любом случае, успехов вам!
StopKran
0
Подскажите, а что вообще содержится в этих белых листах? Какие железки кроме вайфай карт? Я собираюсь у себя на thinkpad s430 поменять память и поставить ssd, мне для этого надо тоже заморачиваться и выбирать что-то совместимое или перепрошивать биос?
StopKran
0
В какой-то момент мы в Мытищинской школе программистов обсуждали перевод начального обучения на новый язык программирования (на начальных курсах преподаётся паскаль, затем можно взять курсы по другим языкам). Так вот, посмотрев на все языки, мы пришли к тому, что самым идеальным для обучения является язык Lua. В первую очередь потому что на нём можно нормально преподать императивное программирование, и он не настолько устаревший как паскаль, к тому же он интегрируется с Си.
Но в итоге так и не стали на него переходить, именно по причине того, что он имеет достаточно ограниченую популярность, как и паскаль.

Сейчас по опыту наших коллег из МЦНМО и ЛКШ, переводим обучение на Python. Для обучения конечно он не лучший, но популярный. Посмотрим, что из этого выйдет.

Что касается объектно ориентированного программирования оно не нужно на начальных стадиях обучения. Для начала нужно хорошо вдолбить детям императивную модель, потом процедурную, и уже потом объектную. А объектной модели можно обучать уже на нормальном объектноориентированном языке.
Но вот обучать изначально на джаве не получится, потому что ребёнок обязательно спросит, а что такое «static» и что такое «class», а почему вот так. По ответам: врать детям не хорошо (тем более с точки зрения преподавательской этики), а даже если врать он всё равно найдёт и в мозгах у него начнётся каша.
То же самое касается вашего:
program (String arguments[] \execution time command line parameters\ )
{&
Console.write_line(«Hallo, world!»);
&}

На c++ просто слишком много заморочек и слишком сложный синтаксис.

Функциональное программирование тоже на начальных этапах не нужно.

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

А ещё я не понял, как у вас объявляется метод в классе.
StopKran
0
Обсуждали подчёркивание ссылок как-то раз с бывшим арт директором hh.ru. Он высказал следующую правильную на мой взгляд мысль (не дословно). Подчёркивать ссылки нужно в зависимости от контекста. Если пользователю требуется сделать какое-то действие, например — прочитать статью, он обязательно попробует кликнуть на заголовок, в не зависимости от того, подчёркнут он, или нет. И так происходит с любым элементом управления. Если пользователь видит не подчёркнутую надпись «Открыть все предложения» или «Заработать две тысячи долларов» или любую другую, без смысловой нагрузки вне контекста того, что это ссылка, он и так понимает, что это должно быть ссылкой. Единственное, когда ссылки подчёркивать действительно нужно, это когда ссылки находятся внутри текста.

А ещё, я не заметил, когда на хабре стали подчёркивать все ссылки, в том числе и заголовки. Раньше не было.
StopKran
+4
Обоих значит нужно пнуть =)

То, что у вас на фоне в ритме каша, это скорее вопросы качества гитары, оборудования, ну и сведения да. А вот перегруженная гитара у вас звучит как типичная гитара в русском роке. Не хватает атаки, динамики.
На самом деле в этом звуке я узнаю себя, примерно год назад. Звукоизвлечение у меня было на примерно таком же уровне, хотя и играл вещи немножечко посложнее. А потом я решил походить на курсы к преподавателю. Пришёл, сыграл ему, что умел. Потом он взял, и сыграл то же самое. И тут я понял, что я что-то делаю не так. Ноты то одни и те же, даже аппликатура одна и та же, а звук у него в разы лучше. Секрет на самом деле прост, надо просто сильнее бить по струнам. Гораздо сильнее. Прям вх**чивать по струнам. Но от этого в звуке появляется грязь. А вот как избавится от грязи, тут уже много разных нюансов. Продолжаю учиться, понимаю, что за это время звук стал гораздо лучше. Но всё равно пока не рискую записываться; перфекционизм даёт о себе знать)

То, что писались с первого дубля, ну и хорошо. Многие известные композиции тоже писались не пойми как.
Многим наверное знакома история со странным звуком в песне Master of Puppets:
Master of Puppets (1986) Для этого соло я использовал Jackson Randy Rhoads V, Когда вы слушаете это соло, можно заметить странный звук после спокойной части, как будто я извлекаю сверхвысокую ноту в середине фразы, как будто я прижимаю струну в районе звукоснимателя. На самом деле я просто стащил струну с накладки грифа. Я потащил струну E вниз и она была прижата на краю грифа. Мы прослушали записанный материал и решили «Как клево. Оставляем». Конечно, мне больше никогда не удавалось воспроизводить этот звук. Этот магический момент навсегда остался запечатленным на ленте для звукозаписи…
И если прислушаться к соло из всем известной песни Smoke on the water, можно услышать, что в соло потом был дозаписан кусочек, с опусканием машинки. Скорее всего, для того что бы забить образовавшуюся пустоту.
Так что писать с одного дубля это на вашей совести. От того пишите вы с одного дубля или с десяти, ваша техника звукоизвлечения не меняется. А она очень сильно влияет на звук. Так что рекомендую вам прокачиваться в этом направлении.
StopKran
+5
Свели действительно хорошо. Впечатлён вашим опытом. Все в основном качают тонны всякого дорогого софта и сэмплов со всем известного сайта, а в итоге ничего пристойного так и не добиваются.
Ударные у вас очень хорошо звучат. Хотя если бы было сыграно на ударке, даже электронной, с теми же семплами, было бы ещё лучше. Но это уже скорее касается исполнения. А вот в средних частотах там где гитара и клавиши получилась каша. И каша вряд ли из за плохого сведения. Тут стоит пнуть гитариста, что бы прокачивал звукоизвлечение. А то выходит уж слишком типичный русский рок, когда вроде бы всё и хорошо, но гитаристу не хватает техники, что бы звук получился таким же крутым, как за рубежом.

Творческих вам успехов!
StopKran
+19
Не надо говорить неправду детям,
Не надо их в неправде убеждать.
Не надо уверять их, что на свете
Лишь тишь да гладь, да божья благодать.
Они поймут. Они ведь тоже люди.
Откройте им, что трудностей не счесть.
Пусть видят де не только то, что будет,
Пусть видят, ясно видят то, что есть.
Преграды часто могут им встречаться,
Случаться могут горе и беда.
Ну, что ж! Ведь кто не знает цену счастья,
Счастливым быть не может никогда!
Ошибок не прощайте, их узнавши, —
Потом они повторятся стократ,
И нас потом воспитанники наши
За то, что мы прощали, не простят.
Е. Евтушенко
StopKran
+1
Конечно, сравнение с BDUF и Agile очень грубы. Просто хочу обратить внимание на то что истории по сути про методологии разработки и есть. Можно в методологию и бутылку водки включить, в конце концов xkcd.ru/323/ И вот истории отражают как методологии влияют на успешность результата.
Но печалит то, что я вижу достаточно много историй о том, что нужно быстро выкатывать релизы, забить на проектирование, и в итоге эта стратегия приносит выигрыш. И по ощущениям все вокруг только так уже и умеют программировать. Да, во многих случаях (например стартапах) быстрые итерации и принцип «You Ain't Gonna Need It» приносят хорошие плоды. Но это не значит что всегда надо делать именно так, и многие к сожалению этого не понимают.

но они обычно всё расписывают в чёрно-белых тонах
Даже истории у программистов дискретные :)
StopKran
+35
Как меня всегда умиляют подобные рассказы. Про тоже самое например вспоминается цитата с баша bash.im/quote/420672.
Дело тут не в том, что как-то делать лучше. Дело в том, как делать в данной конкретной ситуации лучше.
По сути речь идёт про выбор методологии разработки. Первый инженер у вас использовал BDUF и судя по всему зря. Второй использовал Agile и молодец. При этом ваши истории не доказывают того, что Agile допустим лучше. Просто нужно уметь выбирать. Кто-то делает это плохо, кто-то хорошо.

Истории сами по себе хороши, но почему то все всегда забывают сказать о том, что это доказывает, что нужно думать, а не то, что нужно писать код не подумав, и натягивать верёвку под шафе, не смотря на то, что это работает в некоторых случаях.
StopKran
0
Ох. У меня вот один хороший друг — бармен. Он про столько всяких мелочей рассказывает. Например если налить сначала алкоголь, а потом сок, то от алкоголя будет чувствоваться горечь. Одни коктейли нужно делать в шейкере, другие прямо в стакане, трети в миксере, четвёртые ещё где-то. А некоторые коктейли нужно взболтать в шейкере со льдом, потом лёд вынуть, выбросить, а в коктейль засыпать новый. о_О
И все эти мелочи влияют на вкус.

Такой аппарат конечно мило — но боюсь не справится)

И да, а почему бы бутылки не подвесить на верх, и вместо насосов использовать земное притяжение?
StopKran
+6
Спасибо за статью, вы просто герой, такое написать, но кажется мне вы немножечко заангажированны =)
А я отношусь к проекту с некоторой долей скептицизма, хотя конечно в душе всё равно болею за разработчиков.

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

Вы сравниваете мультиклет в основном с архитектурами центральных процессоров x86-64, arm, Itanium… То есть с CPU привычных нам девайсов. Все эти CPU разрабатывались как процессоры общего назначения. Это значит что процессор должен уметь эффективно выполнять любую программу. А любая программа — это обычно крайне малый параллелизм инструкций. Мы не можем знать какие программисты будут использовать процессор. А зачем заморачиваться по поводу потоков или тем более обеспечения возможности параллельного выполнения инструкций, если можно написать просто, и на процессорах х86/arm это будет работать более чем сносно.
В этом плане современные массовые архитектуры как-раз очень хороши. Предсказание переходов в данном случае очень полезно, или даже как это было сделано в Itanium — считать обе ветки сразу.

Другое дело если этот процессор всё же специализирован для каких-то вычислений. Тогда вопрос — для каких? Судя по простым ядрам и их предполагаемому большому количеству, процессор нужно сравнивать не с x86/arm/etc… А с видеокартами, или подобными многоядерными системами. Вот вспомним, ещё не так давно, было много разговоров про intel larrabee. И где этот ларраби? Почему интел не выкатила свою супер-многоядерную архитектуру? Я думаю потому что в интел понимают что это бесполезно. Высокий параллелизм инструкция можно обеспечить только в узком классе задач. А почему интел стала делать этот ларраби — скорее всего по моде. Если бы cuda выстрелила, то у интел был бы готов конкурент.

Так что кому нужна такая штука, да ещё и с учётом того, что техпроцесс скорее всего будет не самый современный — мне не понять. Хотя конечно не отказался бы пощупать такой процессор в живую =)

Ещё вопрос, правильно я понял что конвейера в процессоре тоже нет?

P.S. Не считаю себе гуру в процессорах, и ассемблере, я занимаюсь высокоуровневым девелопментом, но в моих глазах ситуация именно такая, какой я её описал.
StopKran
+8
Крутизна! И сразу приходит на ум куча вопросов.
Это мы видим один слой микросхемы или все слои наложенные друг на друга?
А можно ли таким способом «отревёрсинжинерить», чип и сделать свой такой же? Например если чип однослойный?
А если чип многослойный?

Да и вообще очень интересно было бы почитать про процесс копирования чипов, ведь копировали же!
Вроде там даже какие-то защиты сейчас делают? Может быть напишите про это отдельный постик? ;-)
StopKran
+1
Как раз вовремя на первую работу программистом устроился =) С праздником, коллеги!
StopKran
+8
*очень остроумное поздравление* Ура!
StopKran
+5
В идеале конечно «Вход через Хабрахабр». И только попробуйте сказать мне что у вас нет на нём аккаунта! =)
StopKran
0
Вообще самый простой и быстрый способ уничтожения — засунуть винт в микроволновку.

А ещё мне рассказывали байку что как-то раз одна спецслужба переправляла жёсткие диски с секретной информацией на самолёте. Самолёт разбился, жёсткие диски естественно тоже. И если не ошибаюсь около 80% удалось восстановить.
StopKran
+2
По моему больше похоже на сталинскую высотку (:
StopKran
+1
Обе ссылки оказались уже посещёнными =)
StopKran
0
Вобщем рано или поздно, но мелкософт погубит скайп.
Комментарий из публикации, перенесённой в черновики.
Комментарий из публикации, перенесённой в черновики.