Всё-таки неправильно называть эту структуру массивом. IndexedCollection было бы лучше, на мой взгляд.
Можно и так, но тут корень проблемы зародился в самом JavaScript-е, который использует одинаковый синтаксис доступа [] и для массивов, и для хешей.
Для data я бы использовал Map, а для индексов — Set. Эти структуры как раз идеально подходят под эти задачи.
Я не стал их использовать, так как они пока в статусе экспериментальных, и не поддерживаются некоторыми браузерами. В будущем можно будет поменять реализацию, так что на методах это никак не отразится.
Ну или хотя бы стоит создавать их через Object.create(null), а не {} чтобы не тянуть ненужный прототип.
Все опять упирается в сортировку…
Может кто-нибудь уже сделает сервис или приложение, которое показывало бы ленты хабра, но в соответствии с более продвинутыми настройками и фильтрами, настраиваемые пользователем: например без корпоративных блогов, или с определенным количеством просмотров/комментариев, или при достижении определенного рейтинга, или только от участников с определенным рейтингом/историей…
Идея геопакета хороша, но мне кажется основная проблема здесь не как назвать классы и методы, а как максимально автоматично заскриптовать сбор данных и обновления для обновления этого пактета. Понятно, что список стран и крупных городов будет относительно статичным, но все что ниже обновляется очень активно, тем более в масштабах планеты.
Есть много много разных БД, и для разных целей и разных местностей подходят разные базы. Например для России есть регулярно обновляемый КЛАДР, но в нем только адреса, нет геокоординат, нет возможности искать по запросам типа «Кафе у Ашота», и она не переведена на другие языки. У других стран есть свои подобные базы, есть базы OpenStreet, но у всех чего-то не хватает.
В общем, было бы хорошо иметь такую аггрегированную базу всего, и пакет, который бы к с ней работал, но подозреваю, что в итоге получится что-то типа геосервисов Гугла или Яндекса, который одному человеку не потянуть.
Думаю, что то время сборки и развертывания не являются сколько-нибудь критичными в Enterprise-среде: нет никакой разницы если сборка просходит за минуту или за несколько секунд, так как на думание над кодом разработчику надо потратить часы или дни. Так же не важно время развертывания, так как на согласования, тестирования, подписи и подготовку сопутствующей бюрократии (следование методологии ITIL, которую очень любят в больших компаниях) обычно тоже уходят дни.
В свое время решил проблему отфильтровывания таких товарищей скриптом на GreaseMonkey — при загрузке страници поиска он загружал и парсил все проекты, и подсвечивал те из них, где заказчики из были из определенных стран, и чтобы у них был нормальный фидбек, ну и еще ряд критериев.
Но всё равно, слишком много времени уходит на действия, не связанные с работой, и, соответственно, неоплачиваемые: поиск, вникание в ТЗ, написание предложений, и последующие коммуникации, которые необязательно завершатся выйгранным проектом.
У меня другая ситуация была: один заказчик со штатов, с хорошим фидбеком, все дела, сразу awarded мне проект на 1000 дол, ну я согласился. Биржа с меня тут же сняла комиссию 100 дол, а заказчик пропал не заплатив и даже не предоставив подробное техзадание. Тоже пришлось их пинать очень долго, чтобы отменили все транзакции, но в итоге комиссию удалось вернуть.
Все это заставило задуматься, что получить большой проект сразу — не обязательно есть хорошо, и что лучше начинать с маленького, а уж потом, после знакомства с заказчиком, делать основную массу работы все вне биржи.
Из моего опыта архитектура процессора, можно сказать, вообще не влияет на общую производительность. Гораздо важнее параметрвы конфигурации дискового хранилища и роутеров для связи с этим хранилищем.
Так что статья не раскрывает полную картину.
Асинхронный подход хорош для ограниченного круга задач, типа на один запрос пользователя сгенерировать множество запросов в другие системы. Для реализации бизнес логики чуть сложнее бложика сложность разработки возрастает непропорционально, не смотря на все Futures, Deferred, Promises и т.д. Да что там бизнес-логика — задача по чтению файла строка за строкой с последующим выводом счетчика строк, из задачи для школьников превращается в задачу, не каждому девелоперу по плечу, если решать ее через асинхронный подход. Как потом искать девелоперов, которые смогут поддерживать такой код, и сколько это будет стоить?
Поэтому со статьей согласен полностью.
не могу получить доступ, документацию, софт, и т.д.
Если при приеме на работу мне не дали доступ в систему (или здание), не дали инструментов и документацию, то каким образом это моя проблема?
какие-то системы/библиотеки/софт и т.п. ведут себя
тут должно было быть дописано «не так как ожидалось»… Вот это как раз риски, которые в ИТ являются одним из самых труднопрогнозируемых факторов при оценке объема работ. Например заапгрейдили какую-то систему/библиотеку/софт, а на тестах выясняется что надо апгрейдить еще 10 по цепочке… От места работы это никак не зависит.
недостаточно знаний в какой-то области
если начальник знает, что я чего-то не знаю, ставит меня решать в этой области проблему, и требует немедленный результат, то попахивает некомпетентностью начальника.
Пусть лишний час посидит, разбираясь с библиотекой, читая документацию.
Я не против изредка перерабатывать, но только за отгулы, и только когда того требует исключительная ситуация. Если это становится системой, то это уже признак плохого управления со стороны начальника.
Я бы попробовал поговорить с работником, поинтересовался бы, чем компания может помочь, чтобы ему работалось максимально эффективно. Может его тормозит медленный интернет, или на маленьком экране его ноутбука не помещается софт, с которым он работает, и ему банально приходится слишком много кликать на прокрутки окошек, или дорогая телефонная связь. А может ему теща дома мешает, и он хотел бы в офис вернуться. Не спросишь — не узнаешь. Если не идет на разговор и не хочет возвращаться — тут уж надо считать, стоит его держать или нет.
Не всякий тикет можно закрыть в срок или вообще закрыть, поэтому просроченные тикеты случаются регулярно. Чтобы у начальства не возникало вопросов стараюсь, чтобы все мои действия были задокументированы в тикете и/или в исходящих емайлах. Если тикет из-за чего-то буксует, то информирую начальство о причинах. Причины могут быть разные:
пользователь не присылает скриншот или шаги, как воспроизвести проблему
не могу получить доступ, документацию, софт, и т.д.
какие-то системы/библиотеки/софт и т.п. ведут себя
недостаточно знаний в какой-то области (берёт годы, чтобы научится)
Какая бы причина не была, она или будет изложена в тикете, или другим способом доведена до начальства. В конечном итоге я просто стараюсь помочь начальству, чтобы у него была ясная картина где складывается дефицит каких-то ресурсов, где надо пересмотреть SLA, а где нужны организационные изменения.
Гипотетический крайний случай — если я никому ничего не сказал, на емайлы не отвечаю, в онлайне не появляюсь, и тикеты не закрываю, то когда я обратно объявлюсь, у меня должна быть какая-то весомая причина, почему я никого не предупредил (например, машина сбила). Иначе, я исхожу из того, что максимум мне это простят один раз, а потом уволят.
Я последние 3 года работаю программистом удаленно, и это на данный момент лучший режим работы, который у меня был за мою 15+ летнюю карьеру.
Это не фриланс, это именно работа в компании как если бы это было в офисе, с белой гарантированной зарплатой, соцпакетом, и т.п, но из дома.
Так вот: я обязан быть на рабочем месте у компа в рабочее время. Это требование бизнеса. Если мне куда-то надо отойти, то все, что от меня требуется — уведомить моих коллег по емайлу. Контроль осуществляется через MS Lync — он просто показывет мой статус желтым если я со своего компа не активен, ну и пишет сколько минут/часов/дней я не активен. Если я никому ничего не скажу и уйду на 2 часа, мои коллеги и менеджеры это заметят. Короче говоря, отойти по делам можно, но так как это должно сопровождаться некоей координацией с коллегами, то проще получается не злоупотреблять.
Но самый главный момент — благодаря тому, что не надо тратить время на дорогу и обед у меня освобождается 3 часа в день. Это огромное количество времени, которого хватает на все дела без необходимость брать отгулы, да и вообще позволяет иметь жизнь помимо работы. Эта привилегия мотивирует меня работать так, чтобы у начальства даже вопросов не возникало по целесообразности этого режима.
Так что я двумя рукам "за" удаленку. Но я против контроля за экраном сотрудника.
Лучше контролировать сделанную работу: закрытые тикеты, закоммиченые файлы, отправленные по корпоративной почте емайлы, и т.п.)
Программирование еще пока не имеет формальных градаций, в отличие от других профессий. Например, у врачей и учителей есть категории, у слесарей есть разряды, и т.п. Программирование же молодо, поэтому стандартов нет, и поэтому каждый придумывает свои критерии оценки, кто во что горазд. Кто-то на собеседованиях спрашивает про форму люков, кто-то про бинарные деревья, а кто-то заставляет гуглить и писать на заведомо незнакомом языке (ну типа оценить как быстро кандидат может находить информацию). Но если смотреть на тех же слесарей, например, то на заводе слесарь 1-го разряда делает свою работу, а 6-го — свою. Так же и в программировании: есть 90% рутинных простых работ, для которых достаточно программиста 1..4-го разряда, а есть 10% нетривиальных задач, где понадобятся совместные усилия программиста 6 разряда, архитектора, бизнес-аналитика и прочих начальников. Для задач уровня 1-го разряда знание алгоритмов не обязательно, а 6-го — обязательно, но не достаточно.
Для 90% рутинного каждодневного кодинга в тривиальных области типа биллинга и учета, знание алгоритмов не требуется, имхо. Для оставшихся 10% нетривиальных задач знание алгоритмов возможно потребуется, но не факт, что этого будет достаточно — гораздо важнее может оказаться знать, к примеру, на скольких миллионах записей начнет затыкаться Oracle, с тем чтобы решить, нужен ли он вообще, или может можно файлами обойтись, и исходя из этого оптимально спроэктировать жизненный цикл данных.
Можно успешно кодить в группе 90% большинства, при этом набираться опыта, и постепенно переходить к 10% гуру.
Можно и так, но тут корень проблемы зародился в самом JavaScript-е, который использует одинаковый синтаксис доступа [] и для массивов, и для хешей.
Я не стал их использовать, так как они пока в статусе экспериментальных, и не поддерживаются некоторыми браузерами. В будущем можно будет поменять реализацию, так что на методах это никак не отразится.
Спасибо, исправлю в следующем коммите.
Может кто-нибудь уже сделает сервис или приложение, которое показывало бы ленты хабра, но в соответствии с более продвинутыми настройками и фильтрами, настраиваемые пользователем: например без корпоративных блогов, или с определенным количеством просмотров/комментариев, или при достижении определенного рейтинга, или только от участников с определенным рейтингом/историей…
Есть много много разных БД, и для разных целей и разных местностей подходят разные базы. Например для России есть регулярно обновляемый КЛАДР, но в нем только адреса, нет геокоординат, нет возможности искать по запросам типа «Кафе у Ашота», и она не переведена на другие языки. У других стран есть свои подобные базы, есть базы OpenStreet, но у всех чего-то не хватает.
В общем, было бы хорошо иметь такую аггрегированную базу всего, и пакет, который бы к с ней работал, но подозреваю, что в итоге получится что-то типа геосервисов Гугла или Яндекса, который одному человеку не потянуть.
В свое время решил проблему отфильтровывания таких товарищей скриптом на GreaseMonkey — при загрузке страници поиска он загружал и парсил все проекты, и подсвечивал те из них, где заказчики из были из определенных стран, и чтобы у них был нормальный фидбек, ну и еще ряд критериев.
Но всё равно, слишком много времени уходит на действия, не связанные с работой, и, соответственно, неоплачиваемые: поиск, вникание в ТЗ, написание предложений, и последующие коммуникации, которые необязательно завершатся выйгранным проектом.
Все это заставило задуматься, что получить большой проект сразу — не обязательно есть хорошо, и что лучше начинать с маленького, а уж потом, после знакомства с заказчиком, делать основную массу работы все вне биржи.
Так что статья не раскрывает полную картину.
Поэтому со статьей согласен полностью.
тут должно было быть дописано «не так как ожидалось»… Вот это как раз риски, которые в ИТ являются одним из самых труднопрогнозируемых факторов при оценке объема работ. Например заапгрейдили какую-то систему/библиотеку/софт, а на тестах выясняется что надо апгрейдить еще 10 по цепочке… От места работы это никак не зависит.
если начальник знает, что я чего-то не знаю, ставит меня решать в этой области проблему, и требует немедленный результат, то попахивает некомпетентностью начальника.
Я не против изредка перерабатывать, но только за отгулы, и только когда того требует исключительная ситуация. Если это становится системой, то это уже признак плохого управления со стороны начальника.
Какая бы причина не была, она или будет изложена в тикете, или другим способом доведена до начальства. В конечном итоге я просто стараюсь помочь начальству, чтобы у него была ясная картина где складывается дефицит каких-то ресурсов, где надо пересмотреть SLA, а где нужны организационные изменения.
Гипотетический крайний случай — если я никому ничего не сказал, на емайлы не отвечаю, в онлайне не появляюсь, и тикеты не закрываю, то когда я обратно объявлюсь, у меня должна быть какая-то весомая причина, почему я никого не предупредил (например, машина сбила). Иначе, я исхожу из того, что максимум мне это простят один раз, а потом уволят.
Это не фриланс, это именно работа в компании как если бы это было в офисе, с белой гарантированной зарплатой, соцпакетом, и т.п, но из дома.
Так вот: я обязан быть на рабочем месте у компа в рабочее время. Это требование бизнеса. Если мне куда-то надо отойти, то все, что от меня требуется — уведомить моих коллег по емайлу. Контроль осуществляется через MS Lync — он просто показывет мой статус желтым если я со своего компа не активен, ну и пишет сколько минут/часов/дней я не активен. Если я никому ничего не скажу и уйду на 2 часа, мои коллеги и менеджеры это заметят. Короче говоря, отойти по делам можно, но так как это должно сопровождаться некоей координацией с коллегами, то проще получается не злоупотреблять.
Но самый главный момент — благодаря тому, что не надо тратить время на дорогу и обед у меня освобождается 3 часа в день. Это огромное количество времени, которого хватает на все дела без необходимость брать отгулы, да и вообще позволяет иметь жизнь помимо работы. Эта привилегия мотивирует меня работать так, чтобы у начальства даже вопросов не возникало по целесообразности этого режима.
Так что я двумя рукам "за" удаленку. Но я против контроля за экраном сотрудника.
Лучше контролировать сделанную работу: закрытые тикеты, закоммиченые файлы, отправленные по корпоративной почте емайлы, и т.п.)
Можно успешно кодить в группе 90% большинства, при этом набираться опыта, и постепенно переходить к 10% гуру.