500 р комп с гигом оперативы и прочими плюшками уже купить можно - я уже не слежу за этими поделками - может уже и дальше ушли

бсд, который фрибсд? )

бсд, который фрибсд? )

Да

да, ibm в свои большие машины ставит ppc сотнями. но это не потому, что ppc хоть чем-то лучше интела, а потому, что у них десятилетиями ничегоне меняется

надежность же. не зря банковский сектор на ppc сидит

надежность же. не зря банковский сектор на ppc сидит

Легаси - работает не трогай

+ полно монолитного софта, написанного хрен знает когда и не умеющего хорошо параллелиться

+ полно монолитного софта, написанного хрен знает когда и не умеющего хорошо параллелиться

Да это поле непаханое для стартапов и молодых миллиард.....)))

http://apple.stackexchange.com/a/9

Да это поле непаханое для стартапов и молодых миллиард.....)))

осваивают потихоньку )

https://github.com/upspin/upspin

Уже кидали

Ойла, в слаке кидали

а я в слаке не сижу

и я перед тем, как кидать, посмотрел, тут не нашел

Вообще интересные проекты

Есть проект где микросервисы находятся в одном неймспейс

Что-то вроде репозитория для AWS lambda

Но децентрализованно

Что лучшее для организации чата взять? 1. Каналы с правами доступа 2. Общение Один на один 3. Список участников и их статус 4. Socket.io + JSON API fallback 5. Хранение сообщений на сервере 6. Поиск по сообщениям 7. Уметь держать 10000 сообщений в секунду

webrtc с контролем по вебсокетам да и всё

Ну p2p только вебртс и подразумевает

Добавил пункт 5 и 6

Если это веб

Ахвот

Оно что

)

Перефразировал p2p

ну — значит к каналу контроля автоматически дамп

тьфу

так это совсем другое %))

Из готового что-то было

Но все не продакшн

В общем-то это и на стандартной хорошо делается

Ещё раз: Что лучшее для организации чата взять? 1. Каналы с правами доступа 2. Общение Один на один 3. Список участников и их статус 4. Socket.io + JSON API fallback 5. Хранение сообщений на сервере 6. Поиск по сообщениям 7. Уметь держать 10000 сообщений в секунду

NodeJS

NodeJS

тьфу

вообще есть glue

NodeJS

В там что?)

Пятница, сегодня можно.\

он в целом готов для прода

Там тоже самое :)

А в какой бд хранить сообщени?

я бы взял резинку

А поиск?:)

А поиск?:)

простой навернуть не проблема

а для более сложного — кормить сфинксу

Свои сервера или облако?

Свои

А разница в чем ?)

dynamodb от амазона заходит под высокие нагрузки, пуш изменений, и легкость обслуживания

Напомните, этот чатик сейчас о чем? У Дениса в его экосистеме не нашлось более подходящего?

О го

О реализация чата на го

А есть сервера с MTProto?

А в какой бд хранить сообщени?

в той про которую что-то умеют те кто будет это все писать

а вы считаете что комитить в master как основную ветку разработки - плохо? поясните если не трудно :)

а вы считаете что комитить в master как основную ветку разработки - плохо? поясните если не трудно :)

Да плохо Пушить только в девелоп, обязательно тестить девелоп билды и потом мерджить с мэйном

А ещё лучше иметь один девелоп рут, и вместо мастера кучу веток с названиями версий

Да плохо Пушить только в девелоп, обязательно тестить девелоп билды и потом мерджить с мэйном

а почему наоборот не рассматривать master как development branch, а для релизов (будь то candidate или полноценный) открыть ветку release? мой аргумент довольно прост: легко ошибиться и закомитить в master, но сложнее по ошибке закомитить в release branch

а почему наоборот не рассматривать master как development branch, а для релизов (будь то candidate или полноценный) открыть ветку release? мой аргумент довольно прост: легко ошибиться и закомитить в master, но сложнее по ошибке закомитить в release branch

Потому что гит так устроен Да и можно запретить пуш в мастер

git, по моему понятию, устроен так что им можно пользоваться как разработчику удобно, т.е. master = release это одна из идеалогий, не так ли?

git, по моему понятию, устроен так что им можно пользоваться как разработчику удобно, т.е. master = release это одна из идеалогий, не так ли?

Ты в эзотерику не лезь лучше Делай как принято

Либо делай как тебе угодно Потом прийдут люди в проект и (а гит создан для коллективной разработки) после осознания архитектуры ветвления пошлют тебя нахуй и уйдут с контрибуторов

Потому что гит так устроен Да и можно запретить пуш в мастер

ничего он так не устроен и релиз бранчи -- нормальная практика

а почему наоборот не рассматривать master как development branch, а для релизов (будь то candidate или полноценный) открыть ветку release? мой аргумент довольно прост: легко ошибиться и закомитить в master, но сложнее по ошибке закомитить в release branch

нормальный способ работы если тебе так удобно

ERROR: S client not available

Либо делай как тебе угодно Потом прийдут люди в проект и (а гит создан для коллективной разработки) после осознания архитектуры ветвления пошлют тебя нахуй и уйдут с контрибуторов

holy wars всегда были и никуда не пропадут, я скорее ищу весомые аргументы а не "так принято и цыц!", я свой аргумент пояснил, почему не рассматриваю master как release ветку

нормальный способ работы если тебе так удобно

Я написал ветвления на версии А он про мастер для девелопа

я понял про что он

и ничего страшного в такой модели нет. есть люди которым так удобно и которые так работают

про "так устроен гит" -- это вообще сказки

и ничего страшного в такой модели нет. есть люди которым так удобно и которые так работают

Давай репы

ну раз уж мы тут то пусть примером будет https://github.com/golang/go

в мастер идут коммиты. релизы -- отдельные бранчи

кстати да, release-branch.go1.8

ну раз уж мы тут то пусть примером будет https://github.com/golang/go

Сразу же пуши идут в мастер? Мастер - самая самая последняя версия, релизы - константные не изменяемые Дев - для ранней разработки, когда ещё не оттестировано

Сразу же пуши идут в мастер? Мастер - самая самая последняя версия, релизы - константные не изменяемые Дев - для ранней разработки, когда ещё не оттестировано

ну сам посмотри историю

а главное, к чему были разговоры про "так устроен гит" ?

а главное, к чему были разговоры про "так устроен гит" ?

Ты багнутый не доделанный код пушишь в мастер?

Читай в контексте мои сообщения выше

И не интерпритируй как захочется

ну вот ты мазаться начал ) я багнутый недоделанный код не пишу. исключительно без багов и доделанный

Потому что гит так устроен Да и можно запретить пуш в мастер

действительно, большой простор для интерпретаций

ну вот ты мазаться начал ) я багнутый недоделанный код не пишу. исключительно без багов и доделанный

И даже самые сложные таски за 10 минут

Холодно

по сути мастер можно прозвать как угодно, можно назвать его "wonderland" по желанию

я думаю всем будет очевидно что это не релиз)

жаль что часто tag'ами не пользуются, очень удобно

я вижу что довольно часто пользуются

Для разработок надо делать отдельные ветки типа develop или feature/название и тд:) пушить в мастер тупо, мало кто так делает, обычно мержут в мастер

Для разработок надо делать отдельные ветки типа develop или feature/название и тд:) пушить в мастер тупо, мало кто так делает, обычно мержут в мастер

+

http://www.brendangregg.com/blog/2017-01-31/golang-bcc-bpf-function-tracing.html

Было уже?

Либо делай как тебе угодно Потом прийдут люди в проект и (а гит создан для коллективной разработки) после осознания архитектуры ветвления пошлют тебя нахуй и уйдут с контрибуторов

или не пошлют, потому что и так есть git flow, github flow и gitlab flow. я уже забыл кто есть кто, но какие-то два просто противоречат друг другу. так что как только такие люди будут высказывать мысли о послать - можно смело увольнять

git, по моему понятию, устроен так что им можно пользоваться как разработчику удобно, т.е. master = release это одна из идеалогий, не так ли?

так есть же git/github/gitlab flows. прямо вот каждый и гугли.

надежность же. не зря банковский сектор на ppc сидит

Сидят потому что идиоты

откуда эта идея, что банковский сектор сидит на ppc?

откуда эта идея, что банковский сектор сидит на ppc?

Стереотипы