Жил был один новостной проект. Время шло, одни фичи добавлялись, вторые удалялись... Одной из важнейший фишек была генерация превьюшек к картинкам (thumbnails), а именно - быстрая генерация (до 5 минут) всех thumbnails. Все было хорошо, пока не начали поступать жалобы, что, иногда, генерация не успевает за 5 минут все сделать. Начали "копать" и обнаружили интересную вещь: мы генерим 112 превьюшек к одной картинке. Нашей "радости" не было предела. После небольших дискуссий было решено увеличить maxReplicas до 60 в HPA (проблема возникала когда загружалось больше 80 картинок), так как это самое быстрое и дешевое решение.
Senior Software Engineer
«Дело было вечером, делать было нечего» или краткая история о сравнении производительности языков программирования
"Бенч" дело такое... После нескольких дней бездействия начинается ломка, хочется занять себя чем-нибудь. Иногда я отвлекался на pet-проекты, иногда на чтение литератыры... Сейчас же я расскажу о том что случилось во время последнего "режима ожидания".
Меня многие годы волновала производительность ЯП (в основном интересовал PHP). Список ниже, содержал некоторые мои убеждения, до недавнего времени:
- PHP один из самых медленных языков программирования
- Python быстрее PHP
- Ruby быстрее PHP
- C/C++ намного быстрее Python и PHP вместе взятых
- Assembler на порядок быстрее C/C++
Автоматическая документация по коду для API в Laravel
На одном из утренних дэйликов, мобильные разработчики подняли вопрос о том, что документация по API не соответствует действительности. По горячим следам быстро нашли, что действительно есть нестыковки: разработчик пофиксил баг, но не обновил документацию по роуту. Так как такое уже случалось не впервые - была заведена задача на подумать, что можно с этим поделать.
Ждать долго не пришлось, при обновлении на сервере PHP c 7.2 до 7.4 - мы получили страницу с описанием ошибки, вместо документации. Ошибка найдена в библиотеке, которую мы использовали для рендеринга UI документации. ПР на гитхабе был создан быстро, но провисел в статусе open почти неделю. После этого, тикет насчет документации пошел в работу.
История одной интеграции Agora SDK
Всем привет. Меня зовут Дмитрий, и я типичный представитель касты гребцов на галере X. Основной ЯП, который я использую - PHP, но иногда приходится писать на других.
Небольшая особенность CHAR и VARCHAR
Предыстория
Есть небольшой сервер, на котором крутится стандартный LAMP. Все началось с того, что подходит ко мне QA и говорит: «Есть тема, мне нужно перепроверить регистрацию пользователей, можешь удалить старый аккаунт?», «Не вопрос» — ответил я. Суть в том, вход у нас сделан только через социалки. Что бы не нарушать целостность базы удалением аккаунта, я решил просто взять и переименовать UID (пользовательский ID в конкретной социальной сети) в таблице.
Так как UID у всех разный (vk, facebook, google… — числовой UID, linkedin — строковый UID) был использован VARCHAR для хранения. В итоге я добавил символ нижнего подчеркивания `_` к строке, и со спокойной душой отписался: «Проверяй...».
Как я подружил Quickbooks и PHP сайт с помощью Web Connector'а
Немного погуглив я нашел то что искал. Quickbooks — это бухгалтерская программа для малого бизнеса (основной рынок использования США). Это что-то типа 1С но только с нормальным GUI и некоторыми прикольными плюшками. QB — это приложение, которое пользователь ставит у себя на компе (only for Windows) и с помощью пару кликов, разворачивает себе компанию в которой ведет бухгалтерию.
Ладно, теперь я, хотя бы, знаю своего врага в лицо, одной проблемой меньше. Что касается интеграции то тут все немного сложнее. С чем можно интегрировать QB вы можете посмотреть здесь. Что же мы там видим:
- .NET SDK
- Java SDK
- PHP SDK (Coming Soon)
- Windows Azure SDK
- QuickBooks QBXML v12 SDK (но on desktop scenarios only)
Мда, PHP SDK (Coming Soon) — последняя надежда… Я почти отчаялся, но меня спасло это. Что же эта за штука такая — Web Connector? На офф сайта по этому есть небольшая страничка, на которой предлагают скачать QuickBooks Web Connector Programmer's Guide, и все (по крайней мере мне надоело искать информацию на офф сайте).
История одного Google Chrome расширения
Немного поразмыслив я пришел к варианту google chrome extension:
- Crome использует Blink движок (до апреля 2013 года использовался WebKit), Blink является форком WebKit (а это Safari), так же не забываем новую Opera'у (хотя я все еще использую старую с bookmarks'ами). Таким образом, написав расширения для chrome, мы с минимальными переделками (а то и без них) сможем его портировать на еще 2 браузера
- Нет опыта работы с API Google Chrome
- Google все-таки компания добра :)
Когда мысли немного улеглись, первое что я сделал — это ввел в поиске харба "расширение Google Chrome". Увидев обширный вариант статей по данной теме, я со спокойной душой ушел домой полностью уверенный в том, что завтра с утра прочитав их, к концу рабочего дня дело будет 'в шляпе' (как же я тогда ошибался). Прочитав парочку их них я имел общее представление о том как это работает, но этого оказалось мало для воплащения моих идей. Что ж, приступим…
Information
- Rating
- Does not participate
- Location
- Беларусь
- Registered
- Activity