Комментарии 91
С трудом верится. Может быть где-то в настройках аккаунта разработчика указан домен вашей компании?
В тех же гуглокартах с самого начала (2008?) надо было получать ключ чтоб отображать карты в вебе, иначе фрейм ругался на посторонний домен.
Вы пробовали открыть фрейм с Я.Картами с вашим ключом на совсем «левом» домене?
В настройках ключа прописываются разрешённые домены
В подавляющем большинстве ключи заимствуют не для своего сайта, чтобы по-быстрому выкачать тайлы или геокодировать сотню тысяч адресов. А добавить в скрипт нужный referer не составляет труда.
Настройки доменов (CORS) — для запрета встраивания карты на другой сайт, а геокодирование — по другому ключу.
С тайлами проблемы нет — открыть их в паблик доступ без ключа =)
Проксировать геокодирование через бекенд?)
Upd:
Геокодировать через бекенд дешевле, т.к. можно держать кеш до 30 дней по условиям использования. (зависит от вашей нагрузки)
Быстрее будет сделать несколько ключей, чем проходить csrf. Я понимаю что это щит и меч и борьба до бесконечности. Но на своём бекенде можно делать рейт лимиты и блэк листы. В общем это лучше чем просто ключ наружу и геокод с фронта, лучше в плане защиты от добрых соседей.
Можно геокодить только после рекапчи, относительно новая — без ввода символов и чекбоксов.
Конечно если хочешь это все обходится, но это вопрос ресурсов, я бы просто взял другой или создал несколько аккаунтов. Меньше кода — лучше.
Даже не верится в это..
Задачки про гномиков спрашивают у программистов, а авторизацию к API придумывают менеджеры. Вот как-то так и выходит.
А молоко от их присутствия не киснет?
А то бедные менеджеры прямо во всём виноваты, прямо выгребная яма ответственности, всё туда можно спихнуть.
1. Много костылей — это менеджеры торопили.
2. Идиотская дыра в безопасности — да это менеджеры приказали забить на безопасность, надо новую версию выпускать.
3. 5 лет не фиксится баг в 1С — да там менеджеры вообще за работой твоей не следят, зачем стараться, взял фичу-однодневку из таск-трекера и пилишь её месяц.
4. Да наш PM следит постоянно за нами, проводит проверки, постоянно пальцами тыкает в косяки, так ни в какой «поток» не войдёшь.
Много следят за тобой менеджеры — плохо, мало следят — плохо, торопят — плохо, не торопят — плохо. Ну чёт везде прям плохие они, менеджеры эти.
Вот и в случае API карт — вот прямо менеджер сказал — «в скрипте оставьте свободно, чтобы кто угодно мог использовать». Вот прям словами, приказом? А что, даже в таком случае умного техлида не хватило подойти и сказать «ребят, чушь творим, Гугл по другому делает».
В этом смысле некоторые программисты мало чем отличаются от, допустим, отделочников-забулдыг, у которых виноват бригадир, заказчик, предыдущий отделочник, «кисть не дают, туды её в качель».
При этом каждый второй в комментариях и статьях наделяет своё ремесло просто невероятной важностью, мнит себя строителем цифровых вселенных и вдохновенно надувает щёки как лягушка-бык.
— Нужно по быстрому слепить систему на коленке, разве это сложно?
— Совсем не сложно. Какие требования к ней?
— Никаких, лишь бы работало. Это все равно будет общедоступная система для всех.
Через время:
— Нужно добавить следующие функции (перечень функций для внедрения которых необходимо значительно переделывать всю структуру проекта)
— Тут два варианта, первый быстрые костыли за N времени (но возможно в ущерб отказоустойчивости), или второй основательное переделывание проекта за N*M времени. Какой выбираем?
— Нам нужно это срочно, по этому первый вариант.
Еще через время все возмущаются, почему система иногда не работает или работает так криво! А потому, что изначально система создавалась совсем для другого. Как программисты могут наперед увидеть хотелки менеджеров?
Как программисты могут наперед увидеть хотелки менеджеров?
Отвечу как программист программисту. Нужно спросить у них об этом наперед. Словами через рот. «Что может понадобиться в будущем? Как вы видите законченную систему? Если я сделаю вот так, то потом мы не сможем поддерживать больше чем 100 клиентов. Вас такое устроит? А вы случайно не захотите потом добавить Х? А как насчет Y?».
А когда подобный форс-мажор наступает, то исполнитель и как программист плохой, потому что система не работает, и как специалист — не смог донести риски.
А то бедные менеджеры прямо во всём виноваты
Дык, постановкой задач кто занимается? Менеджерье. Значит оно и виновато.
Потому что профессионалу можно сказать.
1. «Вон там на объекте №3 квартира 25, заштукатурь её по-красоте».
А он ещё позвонит и скажет, что сейчас окон и дверей нет и штукарить нельзя, а то высохнет плохо из-за сквозняка. Ты себя по голове ударишь — точно, совсем из головы вылетело.
А если нужно говорить вот так, чтобы потом не натыкаться на проблемы, то дело наверное ещё и в исполнителе?
2. «Вон там объект № 3, ну всмысле не помнишь, видишь, где синий кран стоит, там на четвёртом этаже хата, в которой вы в прошлый раз дверь ставили, помнишь? Ну вы ещё ломом полотно пробили и обналичку замарали, вспомнил? Ну вот, там надо стены заштукатурить, мешки на складе, мешать то хоть помнишь как? 3 к 1, и воду тепловатую, а не горячую как тогда! Только розетки не замажь, и тазик потом не забудь отмыть, а то всё колом встанет.»
Ну если задачи нужно действительно ставить так, чтобы до человека дошло и он нигде не прошляпился, то это такие программисты действительно не лучше и не ценнее неопытного разнорабочего-подёнщика.
Сорян, телепаты в отпуске.
Приходит такой менеджер и говорит — «Надо сделать авторизацию в API». При этом бизнесовый смысл не озвучивает. Или может вообще не знает сам. Ок, вот тебе механизм API-ключей, которые эмитируются через ЛК.
А потом уже выясняется что по ключам хотели биллить клиентов. А для этого нужен еще SWOT анализ, выработка решений, ограничивающих злонамеренное использование.
Так что, дорогие менеджеры, приносите свои хотелочки вместе с бизнесовым контекстом — получите желаемое, а не минимально удовлетворительный функционал.
А сложные вещи с ним доработает настоящий программист, который может продумать сценарии использования наперёд и обсудить с менеджером, чтобы добиться наилучшего результата.
Тысячи высокообразованных луддитов, которые не хотят думать на пользу дела и просчитывать последствия, а хотят только переводить тупой запрос в тупой код пойдут на митинги и будут громить датацентры.
А раньше над теми таксистами смеялись, которые думать не хотят, а хотят только баранку крутить задорого. Времена «баранок задорого» в IT закончатся быстрее, чем в других сферах.
Здесь не все такие умные, как им хочется казаться, едва какой-нибудь электронный мозг научится вставлять в кодовую базу копипасты со StackOverflow — половину «миддлов» сразу можно выносить из офиса.
А сложные вещи с ним доработает настоящий программист, который может продумать сценарии использования наперёд
Для этого у программиста должна быть перед глазами джира с юзерстори, где зафиксировано — в чем бенефит задачи, какие критерии приемки, и так далее.
И вообще говоря, продумывать сценарии — это задача бизнес-аналитика, а программиста — реализовывать в терминах используемого языка программирования и фреймворка.
Ну вот таких программистов скоро и заменит искусственный интеллект. С простыми вещами он справится.
Была такая баечка. По факту «искусственный интеллект» оказался толпой то ли индусов, то ли китайцев.
Еще раз: что менеджер принес в клювике — то он и получит. Угадывать что он хотел, бегать за ним — никто не обязан, своей работы хватает.
Если из менеджера надо клещами вытягивать суть задачи, ценность для заказчика, место фичи в роадмапе продукта — пусть менеджер страдает и получает ровно то, что просил. Особенно, если в цепочке отсутствуют бизнес-аналитик и архитект.
На бизнес-аналитике закончится, который будет формулировать задачи для ИИ развёрнуто. Вообще это будет наверное как code-as-service — бот-разработчик подключается к вашей базе на гихабе, а ты ему просто формулируешь развернутые задачи. Не смейтесь, машины водить мы ИИ научим, а писать код без обязательств? Ещё проще.
Представляете, как здорово станет, если в компании не останется посторонних людей, не заинтересованных в качестве конечного продукта? :)
Представляете, как здорово станет, если в компании не останется посторонних людей, не заинтересованных в качестве конечного продукта?
Особенно мутного менеджерья, который носит задачи по каплям и из которого надо вытягивать подробности клещами.
Вообще это будет наверное как code-as-service — бот-разработчик подключается к вашей базе на гихабе, а ты ему просто формулируешь развернутые задачи.
А вы смешной. Самое трудоемкое в машинном обучении — это разметка датасетов и тренировка.
Типовые CRUD-ы сейчас например по схеме базы уже можно генерить, но как только вам надо шаг вправо-влево — извольте платить кожаному мешку.
Ну, и развивать и поддерживать реализации таких ботов тоже кто-то будет ручками.
Так что без работы не останемся.
Но если у постановщика каша в голове и во рту — не надо обижаться, что обратно постановщик получает вторую производную этой каши.
А вот «кожаных мешков», которые не думают, пока им не принесут мысль в клювике и не пережуют за них, взявшись рукой за челюсть — вот их надеюсь не уже не будет.
Ок. Документально зафиксированное есть? Хорошо. Критерии приемки есть? Отлично.
Получилось не то, что хотели? См. выше — что было написано, то вам и реализовали.
"Много ли вы видели разработки, когда отдел разработки зовут участвовать в обсуждении ТЗ". Его всегда зовут участвовать. Вы когда сроки выставляете — вы участвуете — уточняете требования и риски. Или вы без сроков работаете? Во время процесса разработки вам никто не мешает уточнять детали. У вас есть 100500 других совещаний на которых это делается. Как это можно не замечать? Я выступал в обеих ролях — и в роли менеджера и в роли программиста — я могу рядом сесть и код продиктовать, но нахрен мне такой программист? И по моему опыту, есть только две причины валить все технические проблемы на менеджмент — либо низкий уровень разработчика, либо не желание работать, либо, и зачастую, то и другое сразу. Если я, как менеджер, даю задачу — надо сейчас и побыстрее, я изначально подразумеваю что потом понадобится тратить больше ресурсов на переработку. А если менеджер этого не понимает — ему нужно на это указать и он это поймёт — язык планирования — это его профессиональный язык.
Его всегда зовут участвовать.
Сюрприз — нет. Не всегда и не везде. Но если зовут — тогда проблема не стоит.
Я уже десятый наверное раз пытаюсь донести, что проблема возникает, когда ТЗ написано без учета существенных критериев счастья заказчика. Корни этого растут в мискоммуникации в цепочке «заказчик — менеджер — постановщик — исполнитель». Но делать исполнителя ответственным за то, что он реализовал не то, что хотела голова цепочки — некорректно.
А сроки просят уточнить, да, когда задача уже принесена менеджером, менеджер нетерпеливо роет копытом и ест мозг Product Owner-у и лиду, и — жертвовать задачами текущего спринта никак нельзя.
Во время процесса разработки вам никто не мешает уточнять детали.
Во время процесса разработки мы заняты разработкой. Когда есть 100500 совещаний — это очень мешает продуктивно работать.
Я выступал в обеих ролях — и в роли менеджера и в роли программиста.
Я тоже. И я как программист не собираюсь брать ответственность за то, что кто-то слева нахерачил в борду не то, что хотел заказчик. А как менеджер я не собираюсь сваливать на исполнителя косяки, вызванные тем, что я прощелкал закачику выесть мозг вопросами чтобы ТЗ блестело.
Если я, как менеджер, даю задачу — надо сейчас и побыстрее, я изначально подразумеваю что потом понадобится тратить больше ресурсов на переработку. А если менеджер этого не понимает — ему нужно на это указать и он это поймёт
Вы не поверите, но далеко не все менеджеры способны это понять. Очень у многих реакция «как так?! в прошлый же раз быстро захерачили! вывсеврети! ленивыезадроты!».
При том, что вроде люди взрослые и знают, что бесплатно ничего не бывает.
Вы работаете в какой-то помойке с низкоквалифицированными коллегами и еще менее квалифицированными менеджерами, судя по вашим комментариям. Это конечно печально, но далеко не везде так
Я работал в разных конторах, в том числе и таких. Это среднестатистические реалии российского софтового бизнеса.
Яндекс, про который речь в статье, кстати, не исключение.
А если к разработчику надо приходить и говорить ...
Видите ли. Я тут давеча писал один сервис, и там тоже необходима была авторизация по ключам. Она была нужна исключительно для разделения контекста, и самый край — экстренного отключения потребителя API в случае компрометаций.
Никакого биллинга там не было, сервис использовался бэкендом другого сервиса, поэтому — вот вам пожалуйста ключи, вот вам админка к API, чтобы эти ключи раздавать потребителям. Никуда на фронт они не утекали.
Что-то мне подсказывает, что в данном кейсе программистам забыли сказать, что ключ поедет аж до фронта. Кто виноват?
— Блин, я же токен от другого аккаунта могу вставить куда угодно, проблема
— Да пофигу, щас напишу в тикете что косяк, потом прикопаются на ревью что слишком много тикетов возвращаю назад. Сделаю все по чертежу и если что скажу что написали, то и получили. Следующий тикет!
В последнее время (лет 5-7) вообще какой-то шквал такого инфантильного отношения к своей работе из серии «я тут ничего не решаю, поэтому мне безразлично».
Тут как бы только два варианта: либо берёшь на работу только тех, кто понимает тебя с полуслова (при этом, вероятно, придётся платить им ЗП выше средней по рынку и завлекать дополнительными плюшками), либо доносишь задачу настолько чётко и детально, чтобы даже ребёнок понял.
Впрочем, очевидно, проблема в том, что Яндекс вполне устраивает ситуация, потому что платить за эту уязвимость будут всё равно его клиенты, а уйти им особо некуда.
Это с ремонтом все просто, что такое дверь и стена все знают. API токены — штука более тонкая, с ними так просто не объяснишь, почему грамотная реализация займёт не 2 дня, а 2 недели.
Вот поэтому и возникают такие ситуации иногда, от неправильной оценки рисков дешёвого решения
В данном случае цепочка исполнителей простой задачи «сделать API ключи для карт» полностью провалила задание (если их можно использовать без ограничения, то смысла в них как в двери без стен) рассуждая на каждой ступени примерно так «ну это же должны решать те кто выше». А потом это отдали Billing team которые посчитали что «не, ну защиту API ключей сделали в API team».
При этом тут нельзя сказать что программисты сделали все правильно, такую очевидную проблему в безопасности очень сложно пропустить если не идти по принципу «а мне больше всех надо чтоль?»
Хм. Пару раз проходил в яндексе собеседования. Не знаю про каких гномиков вы толкуете, все собеседования были весьма адекватными даже при том, что интервьюировали сменяясь несколько человек несколько часов. А вопрос про права на ntfs очень сильно бы удивил своей полной бесполезностью и идиотизмом (поэтому, видимо, такую дичь не спрашивают) — мы ведь о разработчиках говорим? Для вынь-админа-то такой вопрос, наверное, хорош, но на кой чёрт об этом спрашивать разработчика карт или других сервисов? Где они и где нтфс?
Но в общем-то нет особенной разницы между ACL на виндах (читай — на ntfs) и разделением доступа на Амазоне (IAM, Security Groups и прочее). Задачка же вида «придумать модель управления доступом на дереве объектов» ничуть не хуже любой другой яндексовой.
Это знать надо! Это классика!
А почему бы программисту и не знать детали системы, с которой он работает?
Должно быть потому, что подавляющее большинство программистов, ну, скажем, в яндексе, — мы ведь про яндекс начинали, — с нею НЕ работают. И никогда не будут работать.
Я понимаю, что сейчас народишко разбогател безмерно и незаслуженно и нахватал себе макбуков
Выглядит как обидка школоло-недоучки эникея, меняющего ленту в матричном принтере бухгалтерии завода по производству никому не нужных товаров. Да, чувак, работать на маках в очень многих случаях приятнее и эффективнее, чем на вендах. Поэтому профессионалы выбирают себе наиболее удобный из инструментов. Так сложилось, что сейчас это макбуки. А эникеи, ну… продолжайте мечтать о том, как ошарашите интервьюера "нежданчиком" про нтфс ни к селу ни к городу. Потом можете "добить" вопросом о функциях 21h прерывания…
Ну и Рихтера с Руссиновичем они не читали, а зачем.
"Нахрена попу гармонь, гитара папуасу"? Ну, куда вы пришьёте кобыле хвост несомненно уважаемого Руссиновича в экосистеме датацентров яндекса?
Это знать надо! Это классика!
С каких пор не самая лучшая, не самая распространённая, единственная, закрытая по самое немогу фс проприетарной системы стала классикой? Она является типичным представителем своего времени? Нет. Родоначальником направления? Нет. Образцом для подражания? Тоже нет. В некоторой степени этому удовлетворяет юниксовая система прав — они и правда и типична и широко распространена и её знание практически полезно для большинства разработчиков. И то есть сомнения в целесообразности задавания такого вопроса разработчику сервер-сайда. А уж вопрос про нтфс не для вин десктоп разработчика бесполезен более, чем полностью. Актуален сисадминам. Ну, ещё эникей может перед старушками из бухгалтерии выпендриться, да. :)
Поэтому профессионалы выбирают себе наиболее удобный из инструментов. Так сложилось, что сейчас это макбуки
Ну давайте вы не будете с таким апломбом за всех рассуждать. Я не сильно понимаю к чему их автор предыдущего комментария упомянул, но вы в ответ уж совсем спорную вещь сказали. Это если вы под ios разрабатываете, да, у вас к сожалению выбора нет. Во всех остальных случаях, к счастью, можно что угодно другое выбрать.
И то, даже в таком случае, называть ультрабук, а не десктопный мак или пк лучшим инструментом — ооочень спорно. Разве что вам кровь из носу мобильность нужна (а ведь далеко не все разработчики ездят по командировкам), но и в таком случае я бы на основном рабочем месте десктоп предпочел, а ноутбук как дополнение.
Ну давайте вы не будете с таким апломбом за всех рассуждать.
Нет, что вы. Возможно, это прозвучало чересчур категорично, но нет, я совершенно не настаиваю, что это так для всех. Я прекрасно понимаю, что виндовые разработчики, возможно, болшинство выберет что-то иное (хотя знаю виндовых разработчиков на маках). Геймдев для меня совсем неизвестен, полагаю, там очень мощные рабочие станции с кучей крутых видеокарт и нет места макбукам. Но в вебе, серверсайде и прочем энтерпрайзе макбуки едва ли не стандарт. А эти отрасли составляют весьма значительную часть разработки.
Я не сильно понимаю к чему их автор предыдущего комментария упомянул, но вы в ответ уж совсем спорную вещь сказали. Это если вы под ios разрабатываете, да, у вас к сожалению выбора нет. Во всех остальных случаях, к счастью, можно что угодно другое выбрать.
Не знаю почему "к сожалению", макбуки удобны зело суть :). А так — это просто статистика. Везде где работал, да, вот, недавно пособеседовался ещё в десятке (или более мест), если работодатель не жмот, то разработчику на выбор предлагают или десктоп или лэптоп с парой мониторов. Большинство выбирают лэптоп (ну, это же удобно — можно иногда из дома поработать — во многих местах это допускается, либо просто в офисе уйти куда-нибудь в уголок на подушки или в переговорку). И если есть выбор лэптопов, то большинство предпочитают выбрать макбук. Это то, что я видел своими глазами не в одном десятке мест. Не все так делают, далеко не все, но реально большинство.
а не десктопный мак
Работал на десктопном маке. На аймаке. Экран, конечно, здоровенный, но… интерфейс макоси заточен больше на лэптоп, по мощности аймаки у макбуков не выигрывают и при наличии выбора между аймаком и макбуком выбрал бы макбук :). Да и если уж сидеть за этой уродской мелкой лэптоповой клавиатурой, то, хотя бы, на макбуке. А между макбуком и сопоставимым по мощности "другим лэптопом" выбрал бы тоже макбук, поскольку на "другом лэптопе" будет в 90% случаев винда, а я уже давно привык к хорошему, к униксоидным осям и от маздая подташнивает :). Не везде админы допустят на корпоративный лэптоп линукс :-/, а к макоси уже привыкли.
Разве что вам кровь из носу мобильность нужна (а ведь далеко не все разработчики ездят по командировкам)
не обязательно командировки. см выше. даже внутриофисная мобильность рулит, не говоря о WFH (work from home).
но и в таком случае я бы на основном рабочем месте десктоп предпочел, а ноутбук как дополнение
Ага, такой вариант как-то тоже имел место в моей практике — очень удобно, с одной стороны, а с другой — мощности типовых офисных десктопов сравнимы с мощностями типовых лэптопов разработчиков (не касаемся рабочих станций геймдизайнеров и датасайнтистов) и, фактически, десктоп тут — лишняя сущность. В моём варианте лэптоп и десктоп были в разных сетях (десктоп в корпоративной защищённой, лэптоп в обычном интернете), поэтому это имело смысл. А так — зачем плодить сущности?
Но я не навязываю именно такой взгляд на вещи, говорю же, это просто мои наблюдения за окружающей ситуацией. Кто-то предпочитает десктопы, кто-то не любит макоси, но большинство, при наличии возможности выбора выбирают макбуки или "другие". Я сам в данный момент сижу за десктопом и не особо страдаю. Потому, что в текущей конторе к десктопу можно было попросить два монитора, а к лэптопу только один, сейчас регламент смягчили и можно выбить и лэптоп и два монитора — это ещё удобнее, но пока лень менять :).
в вебе, серверсайде и прочем энтерпрайзе макбуки едва ли не стандарт.
Неа. Они красивы, но за те деньги, что за них хотят -лесом, лесом.
Убунту на них не поставишь (сейчас например. T2 мешает), а без убунты разрабатывать в вебе, серверсайде, и прочем энтерпрайзе — печаленька.
Нет, что вы. Возможно, это прозвучало чересчур категорично, но нет, я совершенно не настаиваю, что это так для всех. Я прекрасно понимаю, что виндовые разработчики, возможно, болшинство выберет что-то иное (хотя знаю виндовых разработчиков на маках). Геймдев для меня совсем неизвестен, полагаю, там очень мощные рабочие станции с кучей крутых видеокарт и нет места макбукам. Но в вебе, серверсайде и прочем энтерпрайзе макбуки едва ли не стандарт. А эти отрасли составляют весьма значительную часть разработки.
Ну вот я как разработчик под андроид предпочитаю не маки. Более того, у меня в планах флаттер, и я не собираюсь пересаживаться на мак, планирую приобрести миник и использовать тупо как билд сервер, а разрабатывать и дальше планирую под win иногда по фану пересаживаясь на разные дистры линукса.
Не знаю почему «к сожалению»
Потому что при выборе покупать только мак или мак + вин для комфорта, многие предпочтут сэкономить, даже если маки недолюбливают.
ну, это же удобно — можно иногда из дома поработать
Ну так дома у меня нормальный ПК, с которого я так же смогу поработать. Зачем мне таскать с собой лишнюю железку? Тем более что я часто передвигаюсь пешком (зимой) или на велосипеде, и очень высок риск эту железку угробить.
Да и если уж сидеть за этой уродской мелкой лэптоповой клавиатурой, то, хотя бы, на макбуке. А между макбуком и сопоставимым по мощности «другим лэптопом» выбрал бы тоже макбук
Я там выше писал что вообще не понимаю смысла лептопов как основной машинки, только как дополнительную вижу.
Ну вот я как разработчик под андроид предпочитаю не маки.
Ну, и зашибись!
а разрабатывать и дальше планирую под win
Наверное, тогда вы не откажите в любезности рассказать какие именно преимущества даёт вынь в андроид-разработке? Очень интересно.
Потому что при выборе покупать только мак или мак + вин для комфорта
Какая странная альтернатива. Мак — компьютер, вынь — операционка. Её можно поставить на мак, если надо. Как дуалбутом, так и под параллельсом.
Ну так дома у меня нормальный ПК, с которого я так же смогу поработать. Зачем мне таскать с собой лишнюю железку?
На кой мне на домашнем пк рабочее окружение? Которое часто должно быть подключено к защищённой сети и контролироваться корпоративными админами. Пускать сторонних людей на домашний комп? Данунафиг! Пусть на своих лаптопах и орудуют.
Тем более что я часто передвигаюсь пешком (зимой) или на велосипеде, и очень высок риск эту железку угробить.
Часто падаете? :-О :)
Ну, в общем-то, наличие лаптопа не заставляет его использовать во всех мыслимых конфигурациях :). Можно точно так же дома ПК использовать.
Я там выше писал что вообще не понимаю смысла лептопов как основной машинки
А я выше написал, что наоборот. Причём описал причины. Вы можете описать почему, по-вашему, десктоп лучше лаптопа сравнимой мощности? Было бы интересны объективные причины, а не только факт вашего непонимания :)
Наверное, тогда вы не откажите в любезности рассказать какие именно преимущества даёт вынь в андроид-разработке? Очень интересно.
Никаких особых преимуществ (если забыть про удобное администрирование, домен и вот это все). Мне просто нравится десятка (в отличии от предыдущих систем этого вендора).
Её можно поставить на мак, если надо
Проблема то как раз в железе. Мне не нравится что меня загоняют под одного вендора. Будь Mac OS как винда или линукс, с поддержкой кучи железа, возможно бы и перешел на нее.
На кой мне на домашнем пк рабочее окружение? Которое часто должно быть подключено к защищённой сети и контролироваться корпоративными админами. Пускать сторонних людей на домашний комп? Данунафиг! Пусть на своих лаптопах и орудуют.
Пускать сторонних людей согласен, не нужно. Лично мне чтобы работать из дома, к уже имеющемуся софту ничего добавлять не пришлось, даже open VPN уже стоял. Все что нужно для работы — мне и дома пригодится.
Часто падаете? :-О :)
Зимой могу несколько раз упасть. На велосипеде летом реже, но есть большая вероятность попасть под ливень, а падения более опасные.
Вы можете описать почему, по-вашему, десктоп лучше лаптопа сравнимой мощности? Было бы интересны объективные причины, а не только факт вашего непонимания :)
Во первых расширение, апгрейд и ремонт пк несравненно проще. Железо дешевле. Конфигурацию можно собрать практически на любой вкус. Ну и железо сравнимое по мощности с десктопом либо вообще недостижимо (есть любители пары сотен гигов на домашней машине и последнего i9 в разгоне), либо стоит раза в 3 дороже десктопного, при сравнимой мощности. Причем не всегда адекватно может работать, ибо система охлаждения может не справляться. Причем далеко не все из того что я описал, к сожалению, даже к мак десктопам относится.
Во первых расширение, апгрейд и ремонт пк несравненно проще. Железо дешевле.
Мы же обсуждаем не домашний комп. Это проблемы работодателя :). Апгрейд и ремонт вообще хороши — нам просто дают новый, улучшеный лаптоп :) — красота же!
Ну и железо сравнимое по мощности с десктопом либо вообще недостижимо (есть любители пары сотен гигов на домашней машине и последнего i9 в разгоне), либо стоит раза в 3 дороже десктопного, при сравнимой мощности.
Ай, ладно. Мы же в пределах обычного средне-офисного разработчика обсуждаем проблему. Если не брать геймдев, среднеразработческий офисный десктоп не мощнее среднеразработнического лаптопа. Вам как андроид-девелоперу зачем пара сотен гигов на дев машинке :)?
Мы же обсуждаем не домашний комп.
Ну я предпочитаю на работе и дома иметь схожий набор ПО и пользовательский опыт, а соответственно предпочитаю в офисе так же пользоваться ПК.
Отсюда и все остальное. А дома мне от пришедших в голову хотелок может потребоваться любой апгрейд. Может вздумаю с беком поэкспериментировать или еще чем тяжеловесным.
не яндекс, мимокрокодил.
Насколько это применимо к ключам яндекса — вопрос, разумеется, отдельный.
По существу, раньше все читерили: яндекс выдаёт вам ключ API и разрешает ВАМ 25к запросов в сутки. Ушлый норотт не заморачиваясь кидает запросы в яндекс с клиента… итого профит — каждый КЛИЕНТ вашего сервиса может делать по 25к запросов.
Технически отключили через 1.5 года после предупреждение, а читеры всё равно недовольны и вонь поднимают. Прекрасно…
p.s. Если в озоне так же сделано, это говорит об уровне тамошних мартышек
Сосед случайно не обидится?
Я бы не написал этот пост, если бы уважаемый valshavel не отклонил мой комментарий к статье
«отклонил» — это как? На хабре теперь тоже доступна цензура за бабло (в блогах компаний)?
«Налетай торопись, покупай живопись»
Как спихнуть на соседа счёт за пользование услугами Yandex Maps API или для чего IT гиганту нужен контроль качества