Сталкивался с ещё одной проблемой IE:
Файл отправлялся на сервер, условно говоря, вот так:
/**
* @param {Blob} file
*/
function sendFile(file) {
var XmlHttpObject = new XMLHttpRequest(),
form = new FormData();
form.append('file', file);
XmlHttpObject.send(form);
}
В результате запрос на бэкэнд приходил:
В случае любых браузеров, кроме IE: с заголовком Content-Type: multipart/form-data и содержимым файла в соответствующем виде в теле запроса.
В случае IE: с заголовком Content-Type: application/x-www-form-urlencoded (хотя тело запроса было как в случае multipart/form-data).
Это, в частности, препятствовало привычному использованию php-шного массива $_FILES, пришлось допиливать обёртку для парсинга тела запроса.
Не сталкивались с таким?
Когда-то давно возникла необходимость реализовать поиск по сайту, который учитывал бы все возможные формы слов. Длительный гуглинг привёл меня в итоге не помню куда, где находился этот архив с такими вот файлами (могу залить на гитхаб, если интересует).
В каждом файле представлен 1 корень слова. Синтаксис файла не соответствует ничему известному, т.е. это не regex, хотя и немного похоже.
Вначале в фигурных скобках перечисляются все возможные суффиксы+окончания (далее просто окончания) для слов с этим корнем. Вложенные скобки раскрываются путём склеивания всех перечисленных в них вариантов с буквами перед ними: ьва, ьву, ьвом, ьве и т.д.
после фигурные скобок написано "ев" — это окончание для базовой формы слова (инфинитив для глаголов, ед.число, имен.падеж для сущ и т.д.)
оставшаяся часть первой строки "{л} -ЕВ муж спец." роли не играет, там просто доп.сведения.
И далее, со второй стоки перечисляются основы слов (т.е. то, к чему мы будем крепить окончания)
Т.е. алгоритм должен
раскрыть все фигурные скобки и составить массив возможных окончаний;
найти окончание для базовой формы слова ("ев");
для всех основ слов сгенерировать базовую форму, добавив к концу "ев";
для всех основ слов сгенерировать все возможные формы, добавив каждое из окончаний в массиве из п.1.
Фронтэнд разработчику — почти никогда, бекэнд — случается. Собственно, эта задача появилась не на ровном месте.
Из неё можно сделать вывод, скорее, не о качестве человека как инженера, а о складе ума и способе мышления.
И, по моему мнению, это куда важнее для начинающего разработчика, чем фреймфорки, паттерны и прочее, потому что, как тут уже писали, они выучатся со временем, а вот то, как человек думает, почти невозможно изменить (мы говорим о взрослых людях).
Вот, конкретный пример, с которым я сталкивался:
Есть пачка файлов (около 700), в которых описаны формы слов примерно в таком формате: {ев,ьв{а,у,ом,е,ы,ов,ам,ами,ах}} ев {л} -ЕВ муж спец.
л
полул
человекол
Вложенность в фигурных скобках в первой строке может быть произвольной глубины.
Задача: сформировать файл, в котором будут все возможные формы слов и их базовые варианты через пробел («человекольвами человеколев»), каждая пара в отдельной строке.
Вроде, не так уж сложно. Не головоломка. Не сортировка пузырьком. Просто включаем мозг и пишем рекурсию, да пару циклов. БД или даже ООП тут использовать не требуется.
Собственно, даже код писать не обязательно, если человек сможет объяснить решение на пальцах.
Но 80% кандидатов в джуниоры не справляются.
Так ведь на собеседованиях на программиста обычно никто и не просит вас решать диф.уравнения.
Но логика, абстрактное мышление, воображение, в конце концов — это больше, чем просто выучить операторы языка.
Потому, я думаю, чаще предполагается, что синтаксис конкретного языка соискатель либо знает, либо быстро выучит, и на собеседованиях концентрируются на таких качествах, которые прямо в лоб проверить не всегда возможно, вот и предлагают всякие странные задачки.
Если у вас есть подтверждённый 10ти-летний опыт в программировании, то да, странно, наверное, предполагать, что вы не умеете абстрактно или логически мыслить.
Но в статье речь идёт о начинающем специалисте — и тут как раз есть повод для сомнений и проверок.
И это не отменяет того факта, что неотъемлемым качеством хорошего программиста является способность к абстрактному мышлению.
И проверить наличие этого качества на собеседовании можно с помощью неких задачек.
В идеале — это может быть решение задачи в виде кода на конкретном ЯП.
Но это не всегда уместно и может занять много времени — и тогда приходится выбирать: проверить способность абстрактно мыслить или знание синтаксиса языка.
А мне доводилось самому искать джуниора и собеседовать его по тех.части.
И практика показала, что научиться программировать — выучить операторы, ООП (на уровне «дать определение по учебнику»), — как раз таки намного проще, чем научиться абстрактному мышлению, которое необходимо, чтобы писать алгоритмы, решать задачи и проектировать архитектуру.
Вроде бы от джуниоров этого вначале никто и не ждёт, но хочется ведь рассчитывать на их рост в перспективе.
Т.е. задумка в том, что если соискатель не вполне продвинут в тонкостях работы с БД или плохо знает какой-то конкретный ЯП, но достаточно талантлив, чтобы всё это освоить в ближайшем будущем — это более хороший вариант, чем вызубренные базовые знания при отсутствии способностей к глубокому освоению сути происходящего.
Сейчас есть языки с очень низким порогом входа, и действительно много кандидатов, которые, никогда особо не разбираясь в естественных науках (прямо скажем — троечники), вдруг в свои 25-30 лет решили стать программистами.
Поэтому я как раз думаю, что лучше задавать вопросы и задачки, которые выявят способности к математике и абстрагированию, вместо проверки на знание встроенных классов или функций одного конкретного ЯП.
Шанс нарваться на математика, не способного выучить язык, совсем небольшой.
Также — в смысле "проблемы нет", или в смысле "такая же проблема"?
Сталкивался с ещё одной проблемой IE:
Файл отправлялся на сервер, условно говоря, вот так:
В результате запрос на бэкэнд приходил:
Это, в частности, препятствовало привычному использованию php-шного массива $_FILES, пришлось допиливать обёртку для парсинга тела запроса.
Не сталкивались с таким?
А что насчёт онлайн сервисов? Есть, например, http://pastenow.ru/ и ещё несколько подобных.
Когда-то давно возникла необходимость реализовать поиск по сайту, который учитывал бы все возможные формы слов. Длительный гуглинг привёл меня в итоге не помню куда, где находился этот архив с такими вот файлами (могу залить на гитхаб, если интересует).
В каждом файле представлен 1 корень слова. Синтаксис файла не соответствует ничему известному, т.е. это не regex, хотя и немного похоже.
1я строка " {ев, ьв{а, у, ом, е, ы, ов, ам, ами, ах}} ев {л} ":
И далее, со второй стоки перечисляются основы слов (т.е. то, к чему мы будем крепить окончания)
Т.е. алгоритм должен
Фронтэнд разработчику — почти никогда, бекэнд — случается. Собственно, эта задача появилась не на ровном месте.
Из неё можно сделать вывод, скорее, не о качестве человека как инженера, а о складе ума и способе мышления.
И, по моему мнению, это куда важнее для начинающего разработчика, чем фреймфорки, паттерны и прочее, потому что, как тут уже писали, они выучатся со временем, а вот то, как человек думает, почти невозможно изменить (мы говорим о взрослых людях).
Просто к слову пришлось.
Есть пачка файлов (около 700), в которых описаны формы слов примерно в таком формате:
{ев,ьв{а,у,ом,е,ы,ов,ам,ами,ах}} ев {л} -ЕВ муж спец.
л
полул
человекол
Вложенность в фигурных скобках в первой строке может быть произвольной глубины.
Задача: сформировать файл, в котором будут все возможные формы слов и их базовые варианты через пробел («человекольвами человеколев»), каждая пара в отдельной строке.
Вроде, не так уж сложно. Не головоломка. Не сортировка пузырьком. Просто включаем мозг и пишем рекурсию, да пару циклов. БД или даже ООП тут использовать не требуется.
Собственно, даже код писать не обязательно, если человек сможет объяснить решение на пальцах.
Но 80% кандидатов в джуниоры не справляются.
Но логика, абстрактное мышление, воображение, в конце концов — это больше, чем просто выучить операторы языка.
Потому, я думаю, чаще предполагается, что синтаксис конкретного языка соискатель либо знает, либо быстро выучит, и на собеседованиях концентрируются на таких качествах, которые прямо в лоб проверить не всегда возможно, вот и предлагают всякие странные задачки.
Если у вас есть подтверждённый 10ти-летний опыт в программировании, то да, странно, наверное, предполагать, что вы не умеете абстрактно или логически мыслить.
Но в статье речь идёт о начинающем специалисте — и тут как раз есть повод для сомнений и проверок.
И проверить наличие этого качества на собеседовании можно с помощью неких задачек.
В идеале — это может быть решение задачи в виде кода на конкретном ЯП.
Но это не всегда уместно и может занять много времени — и тогда приходится выбирать: проверить способность абстрактно мыслить или знание синтаксиса языка.
Не сталкивался с таким, но допускаю, что вы правы.
Хотя в статье всё больше упоминаются стартапы — они, думаю, чаще не могут себе такого позволить.
И практика показала, что научиться программировать — выучить операторы, ООП (на уровне «дать определение по учебнику»), — как раз таки намного проще, чем научиться абстрактному мышлению, которое необходимо, чтобы писать алгоритмы, решать задачи и проектировать архитектуру.
Вроде бы от джуниоров этого вначале никто и не ждёт, но хочется ведь рассчитывать на их рост в перспективе.
Т.е. задумка в том, что если соискатель не вполне продвинут в тонкостях работы с БД или плохо знает какой-то конкретный ЯП, но достаточно талантлив, чтобы всё это освоить в ближайшем будущем — это более хороший вариант, чем вызубренные базовые знания при отсутствии способностей к глубокому освоению сути происходящего.
Сейчас есть языки с очень низким порогом входа, и действительно много кандидатов, которые, никогда особо не разбираясь в естественных науках (прямо скажем — троечники), вдруг в свои 25-30 лет решили стать программистами.
Поэтому я как раз думаю, что лучше задавать вопросы и задачки, которые выявят способности к математике и абстрагированию, вместо проверки на знание встроенных классов или функций одного конкретного ЯП.
Шанс нарваться на математика, не способного выучить язык, совсем небольшой.