unity_ultra_hardcore

«поделить на ноль» = «сделать бесконечным»

по процессу?

Шаг на 5 лет назад в разработке интерфейсов. Письмо, не имеющее отдельный урл, — это полная импотенция разработчиков.
Открыл интерфейс, увидел это, сплюнул и закрыл. Спасибо, не нужно.

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

Боже, какая чушь. Ладно бы речь шла об автосиме, но тут-то чего не хватает? Ну или «стрельба с джойстика — не моё» — тоже понятно. Правда, GTA V это, скорее, кино, чем компьютерный экшн.

Как это «на подходе»? Ее уже все прошли, мне кажется.

А почему вы не ориентируетесь на одноразовых клиентов? На нашем проекте около 1000 строк в сумме. Перевести проект нужно один раз, потом еще провести пару итераций правок. Это нам надо будет ежемесячно платить $30 только за то, что несколько наших xliff-файликов лежат в вашем интерфейсе? Я понимаю, что у вас отличный интерфейс и куча плюшек, но я не сумею объяснить бизнесу необходимость в ежемесячной абонентской плате за то, чем мы не будем пользоваться. А отменять подписку, а потом, в случае необходимости в нескольких правках, ее опять продлевать как-то странно.

Их база бесплатная и есть веб-сервис, насколько я помню, это чуть ли не самая полная и достоверная база из бесплатных. Если ее связать с определением IP было бы вообще отлично — по одному IP мы можем узнать кучу информации о клиенте.

Извините, не то скачал, а время редактирования кончилось. cdn.weblab.pro/eHxU9dQD.json

У нас геобаза построена на основе данных geonames. Широта-долгота, интернационализированные названия населенных пунктов, их таймзоны и куча другой информации. То есть мы по IP пользователя смогли бы узнать его часовой пояс, например (в нашем кейсе это довольно важно).
В таком случае не будет нужды заполнять вашу базу всей этой информацией и следить за ее достоверностью: достаточно для базовых случаев отдать то, что уже есть сейчас, а для сложных — отдать ссылку на geoname_id, зная который можно получить более расширенную информацию.
Вот пример выдачи: cdn.weblab.pro/bNtegEu8.json

Не планируете в гео-выдачу добавить geoname_id от geonames.org? У maxmind есть такое поле, очень помогает.

а причем тут озон?

Невежество в ИТ-среде непростительно, а ваше предположение — это чистой воды невежество.

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

Одно другому не мешает: открытый код поможет системе совершенствоваться, а деньги можно зарабатывать на платных SAAS-инсталляциях и поддержке.
Вот прям сейчас у меня открыты две вкладки
getsentry.com и influxdb.com
Оба продукта — это опенсорс, но у обоих продуктов есть платная версия. Софта с подобной моделью распространения сейчас очень много. Мне кажется, что эта модель и есть самая современная и правильная.
У коробочного софта достаточно рано накапливается технический долг (продавать хороший продукт невыгодно — лучше его кое-как подпереть костылями и побыстрее продать), а опенсорс поможет поддерживать качество кода на относительно приемлемом уровне.

У меня там порядка 30 машин и количество будет только расти, очень хорошие ребята.

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

Как то мы с вами вообще не туда ушли.
На мой взгляд любая методология, возведенная в ранг догмы, вредна и ошибочна. Но из каждой методологии можно почерпнуть здравые идеи, из которых и составить что-то своё.
Например, DRY или KISS очень прочно ассоциируются с ООП. Плохие ли это концепции? Однозначно нет. Плохи ли концепции перехода от общего к частному? Однозначно нет.
Вообще, ООП (или SQL) — это не какой-то урод, который портит всем жизнь, а попытка упростить предметную область для нетехнарей. Например, в терминах ООП очень удобно общаться с менеджерами потому что ключеые абстракции «объект» и «действие» очень понятны на интуитивном уровне. SQL, как мы с вами знаем, был придуман примерно для этого же. Кто знает, если бы не это умышленное снижение порога вхождения, где бы сейчас было всё IT? Мне кажется, что оно было бы уделом нердов в растянутых свитерах с тремя высшими, а не достаточно массовой и интересной штукой, которая во многом предопределила нашу современную жизнь.

Ну так это ваш частный (и, согласитесь, крайне редкий) кейс, зачем его приводить как аргумент в споре об общих? В общем и целом (мне показалось, что и вы со мной согласны) аргумент «это медленно» применительно к инструменту наследования несколько не к месту.

Вы уж извините, что я лезу в ваши JS-разборки, но по своему опыту я давно понял: если нет аргументов против какого-то подхода — говори о его скорости. Ну на самом деле, в каком из ваших проектов наследование было узким местом? Я бы серьёзно задумался о его архитектуре (и о выбранной технологии), если бы в рантайме надо было постоянно породжать сотни тысяч объектов (ведь только с такого количества операций можно будет говорить об оверхеде).
А касаемо темы топика: если нативные инструменты либо медленные, либо уродливые и отказаться от них нельзя — то самое время задуматься о макросах/препроцессорах, которые и разработчикам нервы не вымотают лишними буквами, и тормозить не будут, тк развернутся в наиболее оптимальные конструкции.

я ж выше написал: убИдиться вы можете посмотрев на зеленый значок ev-сертификата в адресной строке

боже мой, какая чушь

Можете уточнить о чём идёт речь?
cURL начинает использоваться уже после того, как клиент перевел деньги, если мы с вами об одном и том же.
В данном случае вы сначала попадаете на сайт продавца, оттуда, отправив форму, вы попадаете на страницу оплаты в paypal, там переводите деньги, сайту приходит информация «клиент xxx перевел вам yyy денег», сайт берёт эту информацию и её отправляет в paypal, если она полностью совпадает с платёжными данными, paypal отвечает «VERIFIED» и сайт может считать этот платёж проведенным и подтвержденным ПС.
Где тут cURL может помешать вам что-то увидеть — я даже догадаться не могу.
P.S. от фишинга вас должен защитить зелёный значок ev-сертификата, в котором написано кому он выдан.

А, вы про это. Я упорно настаиваю на том, что задача выявления таких проблем — это задача QA. У профессиональных QA есть всегда набор кейсов вроде аномально длинного имени пользователя.
Но выявление таких багов должно быть делом точечным — есть сценарии вроде «длинное имя пользователя», «длинное слово в названии товара» и именно их невоспроизводимость и должна проверяться на тестовом окружении. А пихать длинное слово во все текстовые ноды страницы и называть это тестированием — это, извините, профанация какая-то.

Скажите, почему производители любой электроники отказывают в гарантии на устройство из-за любого вмешательства в его конструкцию? Чем сложный веб-сайт отличается от сложной электроники? Почему я должен предоставлять гарантию на работоспособность, если пользователь самовольно внёс какие-то изменения в мой сайт?

Какая-то притянутая за уши проблема, я считаю.
Ваша одиннадцатиклассница ломает на моём сайте блок с номером телефона. И блок с ценой. О чем это говорит? Да ни о чем.
Вы пришли с каким-то громким тезисом «все сайты в интернете свёрстаны неправильно», хотя оснований для таких утверждений нет.
Идея, разумеется, здравая, но с очень узкой областью применения: с помощью таких методик можно тестировать только элементы интерфейса (меню, кнопки), а не элементы оформления, коих на обычном сайте на порядок больше.
Попробуйте бутстрап потестировать таким способом. Тоже, считаете, непрофессионально свёрстан?
Проблемы людей, у которых «нет шрифта», «изменен зум» или иным образом целенаправленно сломан мой сайт, я решать не собираюсь. А все остальные кейсы (вроде кривого контента, плохого перевода или сломанного яваскрипта) закрывают тестировщики.

Отличное решение: купить Parallels (3990р) и винду (~5000р) вместо Paragon (590р). Достойное упоминания на хабре.

Попробуйте прочитать то, что я писал выше и свяжите это с темой поста. Речь идёт о поддержке маркдауна мессенджерами. Если я в хипчат через API отошлю <ul><li>list item</li></ul>, то в окне мессенджера появится список. Если я отошлю тоже самое в API Слака — то я получу просто заэскейпленную хтмл-разметку. Понимаете? Речь не вообще о md vs html, а о том, что поддерживают мессенджеры

Ну, предположим, знаю. Причем тут это?

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

На русской клавиатуре это кнопка, расположенная между «Я» и левым шифтом, у вас не так?

Это переключение между вкладками, а переключение между окнами одного приложения — именно через Cmd + ~

Попробуйте Cmd + ~ — должно помочь

Ну я не говорил, что у меня ничего из этого списка сделать не получилось. Но мне кажется, что такие кейсы должны делаться в три клика, а не сношать мне голову эксепшнами «Build failure reason Unexpected error: java.lang.IllegalArgumentException: Argument for NotNull parameter 'artifactsPaths' of jetbrains/buildServer/agent/impl/artifacts/ArtifactsBuilder.setArtifactsPaths must not be null».
Я, признаться, так и не понял что это вообще такое «артефакт». То есть мне нужна автоматизация пайплайна git -> ant -> deploy. Именно это у меня толком и не завелось. Дальше знакомиться с продуктом мне было неохота, если честно, я и так часов шесть потратил.
Про джиру — вы, очевидно, говорите об облачной установке? Она да, неюзабельна полностью, однако если установить её на собственное железо, вполне можно ею пользоваться при тысячах сотрудников и сотнях (а может и больше, не считал) тысяч задач.

Буквально вчера решил ознакомиться с Teamcity. Если честно, почувствовал себя своей бабушкой, которую посадили за 3Dmax. Совершенно непонятные и крайне переусложненные интерфейсы, никаких туториалов, сырые java-эксепшны в билд-логе, никаких шаблонов под типичные операции.
В итоге, я так и не смог настроить сервер под свой тривиальный кейс (очистить папку, сделать чекаут из гита, запустить ant, скопировать сбилженный проект по scp, выполнить удалённые скрипты) и вынужден смотреть на bamboo.
К слову, об Atlassian vs JB: совсем недавно начал знакомиться с Youtrack — и это точно такой же кошмар, в котором разобраться совершенно невозможно. Если Jira под свой (опять же, тривиальный) кейс я настроил мышкой за пять минут, то в случае с YT пришлось писать в поддержку, чтобы узнать как сделать статус задачи по умолчанию (поддержка не помогла, кстати) и два вечера разбираться с их воркфлоу. К слову, редактор воркфлоу, который вроде бы мне должен был помочь, отказался запускаться на OSX и ванильной яве, я оставил isuue в репозитории редактора на гитхабе — и тишина.
Откровенно не понимаю, как можно писать такие хорошие IDE и такие неюзабельные веб-продукты.

Чем в таком случае отдельное окно браузера с вкладкой-чатом отличается от отдельного окна приложения-чата?

Вы вступили в диалог с агрессивным хамом, судя по предыдущим комментам

Вы передёргиваете.
Например, у меня OS X. В доке около 15 иконок и если в какое-то приложение приходит уведомление — я сразу это вижу с любого экрана любого приложения (кроме полноэкранных). В браузере же у меня около 50 вкладок. Как вы считаете, где быстрее найти приложение, требующее внимание: на доке с 15 иконками, в списке Cmd + Tab или в браузере (который нужно ещё найти среди других приложений) среди 100 вкладок?

Я не про весь маркдаун (хотя идеологически, его проще писать руками, чем генерировать автоматически), а про используемые у конкурентов диалекты. У Слака, например, нельзя даже банальный список вывести или таблицу. Да и в целом html (как подможество xml) — это машиночитаемый формат. В html я могу превратить, например, событие, имеющее описание в xml используя xsl-преобразование. В маркдаун уже так не получится — тот же синтаксис таблицы в нём для машинной генерации — просто ад и придётся буквально руками собирать строку.