Вот еще одна история от меня самого, благополучно угнали машину на следующую ночь после окончания КАСКО, следов разбитых стекол нет, как будто открыли с ключа. Далее, через 3 дня, звонок на мой номер телефона с предложением выкупить. Узнали где живу, номер телефона, время окончания страховки. Со страховыми компаниями тоже не все так гладко.
т.е. на каждый запрос вы проверяете наличие файла, потом загружаете его и выполняете действия в фибере? Вы проводили бенчмарки?
А uppercase STATUS, MESSAGE — это что такое? Дикость в уралах (uppercase) вида en/Start — это тоже нормально видимо? Знаете я бы посоветовал никому не делать как вы. Простите конечно, но такое ощущение что вы никогда не работали с нодой.
Вы можете записывать в файл и массив (хотя очень сомнительная фича в экономии 50 байт), но просто делать map перед записью object -> array и при чтении обратный, а по коду всегда работать с объектом
Начинание хорошее, но:
1. Нет смысла экранировать js, в ноде за вас это уже сделали http://nodejs.org/api/modules.html#modules_exports_alias
2. Если файл вдруг не откроется, то у вас будет uncaughtException и на этом все закончится http://nodejs.org/api/stream.html#stream_event_error
3. Для работы с асинхронностью уже написано много либ. Посмотрите на async. Там есть и each и eachLimit.
4. Если уж выбрали CamelCase то пишите в нем, не мешайте все в кучу
5. У Вас много данных возвращается массивами, потом из этого выходит куча кода с магическими индексами. Используйте объекты и читаемые имена, все станет прозрачнее и понятнее
Вообще очень сложно читать, все запутанно и огромными кусками. Разнесите все на простые функции, которые делают одну вещь. Используйте async и последовательность обработок будет наглядной и не забывайте про обработку ошибок.
Как-то давно проходил собеседование с говорящим по-русски, командцем. И когда говоил как-то так, он постоянно переспрашивал, а я долго думал как же это правильно должно звучать и повторял корректно. После этого провала начал переучиваться. Спасибо за статью
Есть путь — SBT, Gradle. Они оба заслуживают внимания, но я попытался использовать более менее привычные инструменты намеренно. Сразу и очень много всего нового не всегда хорошо, может отпугнуть
ну давайте начнем с того, что предполагает REST:
1. Правило для постраения URL: к примеру /client, /client/{id}, /client/{id}/invoice
2. HTTP методы имет определенное значение по отношению к ресурсу.
GET — к ресурсу возвращает список записей
GET — ресурс/{id} — конкретную запись
POST/PUT к ресурсу — создает запись
PUT к конкретному ресурс/{id} — изменяет запись
Да по моему примеру можно составить запрос, безусловно, только срашненько выглядеть он будет. Так вот, если нужна фильтрация сложная мы будем делать "/client/filter" какой-нибудь который будет POST, и так для каждого ресурса. В если отказать от этого и сказать. Ресурсов нет — есть сервисы, каждый сервис поддерживает команды, get, query, mutate, запросы всегда идут через POST. Метод get принимает Selector. В котором описываются все фильтры, Paging в котором offset, limit и так далее. Метод query принимает SQL — like зпрос. Метод mutate — …
Для такого рода API клиентская библиотека пишется единжды, серверная тоже, и главное не нужно ничего переписывать если вдруг нужно фильтровать по еще одному полю, все строго структурировано и единообразно, чем не альтернатива?
Наверно для справочников и CRUD он подойдет, но если чуть дальше, то начинается отсебятина сплошная.
К примеру выполнять фильтрацию крайне не удобно, мне нужно получить все договора где долг по нему больше, меньше, либо равен чему-то. Для этого GET параметры не подойдут, нужен POST и маппинг, или отдельный метод под фильтрацию, а это уже не REST. Или параметров много и они не влезают в GET, тоже делаем POST и в итоге получаем, что реальный REST только для CRUD примитивных операций, все остальное работает по своему. Или отдача постраничная: в REST я на GET должен вернуть массив Entity, как мне вернуть список страниц и другую мета инфу, не нарушая правил, тоже делаем свою отсебятину. А если мне нужны не все поля, а только некоторые, тоже придумываем какой-то параметр.
А если еще все параметры маппить в контроллере Spring MVC, то декларация метода превращается в ужас. Не проще ли использовать какой-то более вменяемый API, в котором уже все это предусмотрено для любой сущности
В Squeryl также можно использовать case classes. На счет описания, а вот вы попробуйте в рантайме получить список таблиц с алиасами и хотя бы список полей с типами и алиасами. А задача банальна — дать возможность через API получать только нужные поля и устанавливать любые фильтры на эти поля. В JPA это очень просто, в Squeryl это чуточку сложнее, в Slick это костыли
Java учили на ходу, сам язык очень простой, вот все что вокруг него заставило потрудиться, чего одно Java EE стоит для не подготовленного человека. Но не так страшен черт, как его малюют.
1. Java реально быстрее
2. ООП и его прелести в больших проектах никто не отменял
3. Огромное количество готовых решений, велосипеды в прошлом, есть все
4. Наличие отличной IDE (автокомплит, дебаг, рефакторинг)
В итоге нет затрат времени на изобретение велосипедов, красивая объектная модель, легко поддерживать, тесты писать сказка (Spring, Mockito), есть поддержка всевозможных CI, Sonar. Если удручает сам язык — пишите на Scala, прекрасно вписывается в архитектуру
Не холивара ради, но примерно год назад писали сервис, который должен был обрабатывать стабильно примерно 5к запросов, при этом кеш физически там никуда не присунешь. Для быстрого старта выбрали mongodb + node.js. И в итоге было 4 физ. сервера и 20 виртуалок Node.js. Нужно было двигаться дальше и смотрели в разные стороны. Смотрели на Go, он действительно очень быстр оказался для нашей задачи, примерно в 4-8 раза быстрее Node.js. В итоге уже год как работает Java (Netty, Morphia) + MongoDB и горя не знаем, хватает 1 физ. сервера и запас мощности 3-4 раза, не говоря уже о гораздо большем сообществе по сравнению с Go и наличие отличной IDE, профайлеров и так далее
Если у вас многопоточное приложение, которое требует Singleton, почему бы не отказаться от ленивой инициализации (если найдется хотя бы один пример при котором она действительно необходима, то у вас явно что-то спроектировано не так) убрать весь этот громоздкий код, медленные синхронизации и жить счастливо?
А uppercase STATUS, MESSAGE — это что такое? Дикость в уралах (uppercase) вида en/Start — это тоже нормально видимо? Знаете я бы посоветовал никому не делать как вы. Простите конечно, но такое ощущение что вы никогда не работали с нодой.
1. Нет смысла экранировать js, в ноде за вас это уже сделали http://nodejs.org/api/modules.html#modules_exports_alias
2. Если файл вдруг не откроется, то у вас будет uncaughtException и на этом все закончится http://nodejs.org/api/stream.html#stream_event_error
3. Для работы с асинхронностью уже написано много либ. Посмотрите на async. Там есть и each и eachLimit.
4. Если уж выбрали CamelCase то пишите в нем, не мешайте все в кучу
5. У Вас много данных возвращается массивами, потом из этого выходит куча кода с магическими индексами. Используйте объекты и читаемые имена, все станет прозрачнее и понятнее
Вообще очень сложно читать, все запутанно и огромными кусками. Разнесите все на простые функции, которые делают одну вещь. Используйте async и последовательность обработок будет наглядной и не забывайте про обработку ошибок.
1. Правило для постраения URL: к примеру /client, /client/{id}, /client/{id}/invoice
2. HTTP методы имет определенное значение по отношению к ресурсу.
GET — к ресурсу возвращает список записей
GET — ресурс/{id} — конкретную запись
POST/PUT к ресурсу — создает запись
PUT к конкретному ресурс/{id} — изменяет запись
Да по моему примеру можно составить запрос, безусловно, только срашненько выглядеть он будет. Так вот, если нужна фильтрация сложная мы будем делать "/client/filter" какой-нибудь который будет POST, и так для каждого ресурса. В если отказать от этого и сказать. Ресурсов нет — есть сервисы, каждый сервис поддерживает команды, get, query, mutate, запросы всегда идут через POST. Метод get принимает Selector. В котором описываются все фильтры, Paging в котором offset, limit и так далее. Метод query принимает SQL — like зпрос. Метод mutate — …
Для такого рода API клиентская библиотека пишется единжды, серверная тоже, и главное не нужно ничего переписывать если вдруг нужно фильтровать по еще одному полю, все строго структурировано и единообразно, чем не альтернатива?
К примеру выполнять фильтрацию крайне не удобно, мне нужно получить все договора где долг по нему больше, меньше, либо равен чему-то. Для этого GET параметры не подойдут, нужен POST и маппинг, или отдельный метод под фильтрацию, а это уже не REST. Или параметров много и они не влезают в GET, тоже делаем POST и в итоге получаем, что реальный REST только для CRUD примитивных операций, все остальное работает по своему. Или отдача постраничная: в REST я на GET должен вернуть массив Entity, как мне вернуть список страниц и другую мета инфу, не нарушая правил, тоже делаем свою отсебятину. А если мне нужны не все поля, а только некоторые, тоже придумываем какой-то параметр.
А если еще все параметры маппить в контроллере Spring MVC, то декларация метода превращается в ужас. Не проще ли использовать какой-то более вменяемый API, в котором уже все это предусмотрено для любой сущности
Разработчик библиотеки писал по этому поводу уже, и мне кажется он полностью прав. Для этой задачи есть специализированные библиотеки, которые прекрасно справляются со своей задачей
https://groups.google.com/forum/#!searchin/squeryl/migration/squeryl/m9ruq6Z1j7A/N_9pxwF-kkUJ
1. Java реально быстрее
2. ООП и его прелести в больших проектах никто не отменял
3. Огромное количество готовых решений, велосипеды в прошлом, есть все
4. Наличие отличной IDE (автокомплит, дебаг, рефакторинг)
В итоге нет затрат времени на изобретение велосипедов, красивая объектная модель, легко поддерживать, тесты писать сказка (Spring, Mockito), есть поддержка всевозможных CI, Sonar. Если удручает сам язык — пишите на Scala, прекрасно вписывается в архитектуру
https://www.youtube.com/watch?v=iB2N8aqwtxc