Обновить
4
Actual Name@edogs

IT

0,3
Рейтинг
20
Подписчики
Отправить сообщение
западные инвесторы, которые вкладывают деньги в локальные IT-проекты
Прямо таки все западные инвесторы и для любого ИТ проекта? amazon, ebay, twitter, groupon, facebook или даже банально habrahabr не подскажете на чем сделаны, на битриксе или друпеле?:)
По нашему опыту, выбор распространённой цмс крупными компаниями делается в следующих случаях:
а) Сайт абсолютно стандартный, где никаких исключений из правил не требуется.
б) Контора абсолютно бюрократизирована, свалить ответственность за выбор проще в случае известной цмс.
в) Абсолютно не важна скорость работы, т.к. большой посещаемости не будет и разница в затратах на железе в 1000% даже погоды не сделает.

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

Но это никак не отменяет оставшихся 10% случаев, где выбор велосипеда оправдан. Когда нужна скорость или когда проект нестандартный или когда и то и другое вместе. А если Вы хотите запулить уникальный стартапчик, то крайне сомнительно что какой-то из инвесторов будет в восторге от запуска его на какой-нибудь джумле, в которой на момент запуска будет 90% неродного кода, при чем будет жестко тормозить.

p.s.: И кстати, это один большой миф (и этот пост на хабре тому подтверждение), что то, что проект сделан на друпеле, никак не гарантирует легкость смены команды разработчиков сайта:) Два переезда таки равны одному пожару в любом случае.
некоторые программисты в ядро лезут. Так в основном не от большого ума, а по незнанию.
Иногда от недостатка времени. Сделать по правильному зачастую в 2 раза дольше чем грязно хакнуть ядро. Нередко время критично.
Скорее «я негодую» на тему «выучил друпел, пытаюсь работать с чужими сайтами на друпел, а там столько непонятного чужого кода» (с) :)
пишут сами, иногда в модулях, порой прям в шаблоне, а нередко дописывая файлы, которые, по сути, являются ядром Drupal.
Хотя в Druapl из коробки есть возможность программировать прямо через веб-интерфейс… такие куски кода значительно проще обнаружить и обслужить.
Но у меня остается вопрос: зачем тогда вам, дорогие программисты, вообще нужен Drupal или другая CMS?

Тут есть минимум три варианта ответа, применение которых часто видим на практике
1) Если речь о серьезном подходе. Решения друпела «из коробки» нередко бывают мягко говоря не быстрыми, если речь идет о конкретной задаче. Модули кэширования опять же в не самых простых ситуациях не особо спасают. А разница между 0.5с и 2с в загрузке сайта нередко более важна, чем простота обслуживания и быстрота запуска сайта.
2) Если речь о фанате заказчике желающем «сайт на drupal», а не на фреймворке. Зачастую «проще дать, чем объяснить почему не хочешь». Вот и вкрячивают свои куски кода всюду, лишь бы в результате висел «лейбл» друпел.
3) Если речь о не стандартной с точки зрения друпела задачи. Друпел может применяться для тех задач что им решаются великолепно, но вместе с тем впихивать в его рамки те задачи, которые великолепно им не решаются — было бы странно, поэтому делают гибрид.
Зачем Вам для _работы_ фуллхд 13-14"?
Не, не будет.
Ширина это хорошо, но здесь же высота никакая. 768 да еще в 21:9 формате на 14" — это считайте эквивалент дай бог 640 при масштабе шрифтов 1 к 1. Это же жуть листинг кода при такой высоте смотреть? Дай бог 1 короткая функция с комментариями влезет, а потом мотай дальше экран туда сюда.
учитывая тонкость современных дисплеев, следующим логичным шагом будет сбацать ноут в формате 21х9, но с 2 дисплеями, где второй будет вытягиваться «из-за спины» первого и давать в результате 21х18 формат.
По большому счету по фиг.
Однако оформлять код отступами можно даже в языках с {}
А вот оформлять код {} в языках с отступами невозможно.
Часть меньше целого.
Вот еще какой момент любопытен, ликвипей вроде в достаточной степени анонимен, терминал можно за нал кажется в отделениях купить, это что теперь — любой гопник на минутку заполучивший карту в руки спишет любую сумму?
Спасибо, до крайности интересная тема. Терминалы от банков и подключать гиморно и с физ.лицами не работают, в общем может быть спасением.

Уточните если можете 2 момента пожалуйста
а) Тарифы для юр.лиц?
б) Цена обнала?

За платежи они берут комиссию за транзакции.
При оплате на карту: 2,7%. При переводе денег с карты на карту: 1.95USD + 1.00%.
Тарифы прямо скажем не самые низкие
И вот здесь не очень понятно. Клиент платит картой, это 2.7%? А что за «перевод с карты на карту» тогда? Что бы потом вывести на свою?
*ситуация при таком раскладе
<p><p>что-то</p>
Хабрапарсер явно скушал реги.
Цель addslashes/stripslashes абсолютно не ясна.
Не вполне понятно зачем array_unique, ситуация при таком раскладе у Вас будет нормальной, хотя на самом деле на нормальную не похожа.
Клево, осталось дождаться нормальных ноутов на иви и можно апгрейдится.
спасибо за upd, хотя конечно немного отжигаете:)

Более точно было бы сказать, что это может привести к сильному росту производительности при частых апдейтах (а не к потере данных:) — выглядит как чистый негатив), а так же указать, что потеря данных возможна только в случае внезапной проблемы на сервере (при 2-ке данные пишутся в кэш диска, кэш ОС, поэтому что бы они утерялись — должно произойти что-то весьма эпическое).

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

-Черт, у него бьется пульс, он же живой!!!
Так что-ли?:) + или — оценку по пульсу Вы не поймете, а то что человек волнуется это к бабке не ходи.
Работает, но фигово, если есть с чем сравнивать.
Амазоновский пульсоксиметр за 10 баксов по сравнению с приложением — просто монстр точности и надежности, и по скорости срабатывания, и по точности, и по работе в движении и по функционалу в конце концов.
С 2-кой? Будет вплоть до разницы на порядок.
В практических задачах это очень заметно на грабберах и/или во время импорта сложных данных в базу.
2-ка нарушает D пусть и на 1 секунду,
innodb_flush_log_at_trx_commit=2 не сильно больше (если кэш на диск часто скидывается, а обычно это именно так), да и вообще — дело в принципе же, а не в размере и частоте:)
для большинства задач REPEATABLE READ не нужен.
Для многих задач и innodb_flush_log_at_trx_commit=2 не создаст проблем. Если 2-ка родит проблему, то вряд ли она будет самой большой проблемой при таком фэиле.

А чем READ_COMMITTED нарушает согласованность и изолированность? ACID READ COMMITTED не нарушает.
InnoDB supports each of the transaction isolation levels described here using different locking strategies. You can enforce a high degree of consistency with the default REPEATABLE READ level, for operations on crucial data where ACID compliance is important. Or you can relax the consistency rules with READ COMMITTED or even READ UNCOMMITTED
Вы намекаете на использование READ COMMITTED, это все же не одно и то же что REPEATABLE READ.

Информация

В рейтинге
2 627-й
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Зарегистрирован
Активность