Деда
потом избавится от AR в API, настроить кеш и будет летать за милую душу
Деда
брал приложения, например месяц, 5-6 дней на backend, остальное на приложение
Деда
И админка на этой теме - http://themicon.co/theme/angle/v3.3.1/backend-jquery/app/dashboard.html
Заказчики пищали от удовольствия
Serhii
Блин, ну опять же обмажусь пхп, в моем селе засмеют меня)))
Деда
Серег, прочитай про 50% прирост скорости в 7.1
Деда
Я не агитирую конечно
Деда
Но задачу твою решит
Serhii
Стоит значит поменять имя и поставить котика на аву
Деда
Александр
так можно никому не говорить
Александр
Побольше бутстрапа, все URL запрятать через ЧПУ и кто узнает, что там под капотом
Александр
пока оно не упадет и не выдаст трейс
Деда
трейс на продакшене отключить 😀
Serhii
Какой-то тайный пхпых узнает своего и начнёт кидаться какахами)
Деда
В общем и целом, обеспечение поддержки высоких нагрузок достигается не языком программирования, а тем, что называется архитектурное решение. Конечно, языки отличаются некоторыми особенностями. Например Java, в отличии от PHP, имеет встроенную поддержку многопоточности. Но это вовсе не может являться главным определяющим фактором, т.к. многие задачи можно распараллелить и с помощью PHP. Поэтому, по моему мнению, выбор языка должен осуществляться из соображений здравого смысла.
Важно выбирать язык, которым хорошо владеет (или может овладеть) команда.
Не менее важно, наличие сообщества разработчиков, использующих данный язык программирования. Это гарантирует наличие библиотек для решения распространненых задач и поможет в решении возникших проблем. Также это упрощает поиск специалистов на рынке труда.
Третий фактор, стоимость разработки и поддержки вашего решения при условии выбора конкретного языка программирования. Например разработка на C++ часто дороже (с точки зрения потраченных сил и времени), чем на Java или PHP.
David
В общем и целом, обеспечение поддержки высоких нагрузок достигается не языком программирования, а тем, что называется архитектурное решение. Конечно, языки отличаются некоторыми особенностями. Например Java, в отличии от PHP, имеет встроенную поддержку многопоточности. Но это вовсе не может являться главным определяющим фактором, т.к. многие задачи можно распараллелить и с помощью PHP. Поэтому, по моему мнению, выбор языка должен осуществляться из соображений здравого смысла.
Важно выбирать язык, которым хорошо владеет (или может овладеть) команда.
Не менее важно, наличие сообщества разработчиков, использующих данный язык программирования. Это гарантирует наличие библиотек для решения распространненых задач и поможет в решении возникших проблем. Также это упрощает поиск специалистов на рынке труда.
Третий фактор, стоимость разработки и поддержки вашего решения при условии выбора конкретного языка программирования. Например разработка на C++ часто дороже (с точки зрения потраченных сил и времени), чем на Java или PHP.
откуда такая статейка?))
Serhii
Даёшь сайт на плюсах!!!
David
или эт ты сам написал?)
Деда
В этой статье я согласен с тем что неважно какой инструмент, важно как сделана архитектура
Деда
А Node, он же js, в отладке полная жопа
Деда
как было так и осталось по сей день
Serhii
Нормально делай нормально будет
Деда
Ути пути )
Serhii
(Только не говори что на пхп)
Деда
Я всегда все делаю нормально, даже FRC
Деда
🤣🤣🤣🤣
Деда
один хер кстати с контекстами где то не то
Serhii
Серёг, ну ты разберёшься, я в тебя верю)
Деда
в свое время опробывал perl, php, ruby, node, и остался на php, но говорю же каждому свой инструмент
Деда
причем не просто пробывал а с погружением на год, полтора
Serhii
Деда
Оооо
Anonymous
Деда
Картинку то я сам схлопывал 😀 через layer
Деда
Anonymous
Димас будет скучать
Деда
C картинкой я вообще опростоволосился
Деда
[self.mediaView roundCorners:(UIRectCornerTopRight | UIRectCornerBottomLeft | UIRectCornerBottomRight) radius:16.0f];
Деда
- (void)roundCorners:(UIRectCorner)corner radius:(CGFloat)radius rect:(CGRect)rect {
UIBezierPath *path = [UIBezierPath bezierPathWithRoundedRect:rect byRoundingCorners:corner cornerRadii:CGSizeMake(radius, radius)];
CAShapeLayer *layer = [[CAShapeLayer alloc] init];
layer.path = path.CGPath;
self.layer.mask = layer;
}
Деда
так вот картинка меняла высоту, а маска оставалась та же
Деда
вот и была она меня иногда 0x0
Serhii
А набрасывал, что мы не хотим тебя понимать, а шлюха то была закопана в другом месте
Деда
Деда
Но признал же верно?
Serhii
Ну да, ты молодец)
Деда
Значит я не безнадежен
Serhii
Так а с контекстами то что не так сейчас?
Деда
🤣🤣🤣🤣😂😂
Деда
Проблема в том что есть два контекста главный и один для кеша и предотвращения дубликатов
Деда
И я тогда не совсем понимал как с ними работать
Деда
Отключал кеш, все начинало работать нормально, но с тормозами и дубликатами порой. Включал обратно, ехала верстка переодически и на экране не все отрисовывалось
Деда
Сам себе усложнил связку RestKit да ещё MagicalRecord
Деда
31 в 11 вечера заставил работать и отложил до конца праздников
Serhii
То есть фрц на мэин контексте, а кэш на приватном?
Деда
Деда
Ну и плюс MagicalRecord наплодил своих
Serhii
Так это всего лишь обертка, он сам по себе не плодит.
Деда
Без FRC все работало без каких то проблем, а тут столкнулся с ним
David
яж говорил 😂
Деда
Ещё же есть parent и child контексты
Serhii
Ну вроде проблем не должно быть. Создал приватный контекст с главного. Внёс в него изменения. Сохранил контекст. Изменения подтянулись в фрц.
Деда
Деда
Но что то не так сделал
Деда
Если сам создавал entity
Serhii
Так тут бы код увидеть
David
я в свое время тоже с контекстами парился кода юзал фрц+MR
David
адок был
Serhii
А то на словах одно, а в коде другое.
Деда
Хотя и делал save
Деда
Serhii
Ну и сейв в МР это отдельная история)
Serhii
Ну завтра кинь как ты делаешь, посмотрим
David
Деда
Ну я думал он сам должен это делать