Даже указатели излишни. Язык должен быть динамически типизированным, как минимум.
Следует помнить, что речь идёт о школе вообще, а не о школе программистов. Зачем экономистам, юристам, литераторам, художникам, артистам, и прочим из этой серии нужно знать про какие-то там указатели?
В некотором роде, язык программирования в школе вообще лишний. Там должна идти речь о работе с техникой и информацией как таковой, а азы программирования лишь на уровне понимания насколько всё сложно и почему в этом мире всё поголовно кривое.
Позовите когда Авраам будет рожать Исаака, Иакова, Иуду и братьев его параллельно за 1 человекомесяц — такие проблемы гораздо ближе к реальности и меня интересует как другие их решают.
То есть, как я понял между строк, для вас важна именно предельная пропускная способность при достаточно жёсткой структуре потока (в том плане что вы не будете его сильно и постоянно менять/расширять).
Мне как раз наоборот: нужна легко изменяемая структура, а ещё лучше мульти-структурность, а сопутствующие потери производительности готов покрывать масштабированием; ну и плюс не хочу привносить лишних человеческих компетенций (читай, С/С++) без нужды.
А неструктурированные данные, в принципе, поддерживаются почти везде. Это как раз не проблема — можно и эмулировать через текстовое поле.
Про redis, кстати, читал замеры — он выдаёт много (3-5-10K/sec — забыл) только на push-операциях; а вот на pull он такой же медленный как и все остальные (1-2К/sec).
Недавно Twitter выпустил некий Storm — github.com/nathanmarz/storm — и описания вашей задачи и этого шторма по крайней мере похожи. К сожалению, я так пока и не понял что именно делает этот шторм, и что конкретно у вас за задача; в частности, почему именно выбор пал на Redis&K (сравнения, показатели, функционал…).
Вопросы: Не пробовали ли? Не примеряли ли? Как и почему подходит или не подходит? Мне на среднюю перспективу тоже нужна реал-таймовая система обработки большого потока событий, вот и смотрю на чужие опыты на этой полянке.
Заработало за пару часов (пишут что активация до 24ч может занять).
Но, как говорится, уже поздно. На gmail-аккаунт навешано много контактов, и теперь их надо перекидывать на свой доменный аккаунт. И никаких утилит по слиянию гугло-профайлов, размеется, нет — всё ручками. Эх, гугл, гугл…
Такая архитектура обычно закладывается на годы вперёд, и это правильно. Но есть нюанс: веб стал невменяемо динамичным, и скорость только нарастает: например, языки появляются и уходят за считанные годы (раньше были хотя бы десятилетия); про фреймворки вообще молчу.
Рассчитана ли ваша система на гетерогенность в плане языков/фреймворков? Например, если в какой-то момент через 2-3-4 года вы поймёте, что python-программистов на рынке стало больше и они лучше, чем php, а скорость обработки запросов в pypy в N раз выше чем в php. Или в результате коллективного умопомрачения мирового масштаба все начнут использовать Java/NodeJS/Go/ещё-что-нибудь. Не суть важно почему.
Я на этот случай держу NTFS-3G установленным, но выключенным. И включаю при такой ошибке; там, кстати, есть ещё консольный ntfsfix в комплекте. А также на случай если надо из мака отформатировать новый NTFS в Disk Utility.
NTFS используется для обмена данными, просто вообще. Между Windows & Linux тоже. Между Win & Lin & OSX тоже. Не считая вообще малонастраиваемые embedded системы, которые exFAT ещё не понимают, зато на ура понимают старый добрый NTFS. Но это так, между делом.
А по делу: когда я говорил что ненадёжно, я имел в виду что реально ненадёжно. Если эти «костыли» кривят NTFS, то родименький chkdsk может всё поправить. Или там, если диск внезапно теряет питание (вынут из USB) в процессе записи мета-инфы.
А вот если такая жопа — сбой записи или кривые костыли (exFAT, кстати, тоже прориетарная от MS и подлежит лицензированию (сюрпрайз! сюрпрайз!), так что в линуксах будет очередной «костыль») — так вот, если жопа случается на exFAT — то всё, никакой chkdsk не поможет, так как копия таблицы только одна и она повреждена. Данные (все или частично) утеряны где-то там в секторах. Причём это бабка надвое сказала что только свежие данные; могут и случайные из старых.
exFAT не работает в Linux'ах out of the box. И он ненадёжен из-за единственной таблицы файлов.
NTFS-3G работает медленно. Скорость записи у меня была порядка 3 MB/sec. Есть решение с родными драйверами — с ними скорость записи порядка 30 MB/sec. См тут или тут.
Что, я неправ? Хорошие белые пушистые компании не будут нанимать нелегалов, ибо зачем бы им себя под штрафы подставлять. А когда решишь легализоваться — 10-летний бан в США. Не так?
Раньше было проще, да. Амнистии всякие. Знал бы куда упаду — соломку бы подстелил, как говорится.
Я обычно гуглю страничку по «h1b cap» самую первую, там официальная сводка. На Aug 12 выбрано 25300 из 65000. Учитывая что оно идёт с Apr 01, то при равномерном потреблении лимит кончится за 11.3 мес, то есть к марту. Хотя на Jul 01 там было 17000, и расчёт был к новому году. Так что потребляется оно неравномерно. Но не так дико как в былые годы.
Да, придётся ждать. Я, конечно, это имею в виду, когда ищу. Ну и там есть ряд исключений: если работодатель на территории кампуса университета, то лимит не действует. Но я таких не встречал; все по городам, в основном.
Понял. Тем не менее, спасибо за ответ. Буду дальше экспериментировать и пробовать. И играть в DV (хотя, с моим-то «везением», проще сразу в H1b ползти — надёжнее :)
Да, поэтому я радуюсь что хотя бы хотят. А что не берут — значит всё-таки выгляжу недостаточно гениальным, чтоб ради меня помучаться с бюрократией. Если точнее, помучаться может и юрист; а вот ждать… Сам запрос на H1b там — 2 недели в премиум-режиме. Подготовка рабочего места для приёма иностранного работника (которая не с миграционным, а с трудовым ведомством) — вот не уверен тут, разные версии есть, от пары недель до пары месяцев.
Спасибо за рассказ. Я тут как раз по этим местам катаюсь, смотрю что и как.
А вот, коль уж 4 года работаете, расскажите как тут искать работу программисту? А то что-то как-то никак не получается. Всё вокруг да около, хотят да не берут. Пытаюсь понять что я делаю не так.
Их никуда переносить вообще не надо. Они просто лежат общие на весь регион, и могут быть использованы из любой зоны доступности. Если быть точнее, то образ быть использован не может никак вообще. Из образа можно только создать том или тома. А вот том уже цепляется к инстансу (строго одному) для доступа к данным, на него можно писать и с него читать.
Я сначало было удивлялся как вы сумели в разных датацентрах образ перекинуть без проблем, когда по моим сведениям это можно только в одном датацентре между разным зонами. А оказалось, что «У Амазона есть несколько Availability Zone: US East, US West, Asia Pacific (Сингапур), Asia Pacific (Токио) и EU – Ирландия».
Хочу вас слегка поправить: по всей статьей использована неправильная терминология. У амазона есть несколько _регионов_ (вот те 5 штук), которые делятся на примерно 2-3 _зоны_доступности_ в каждом регионе. Термина _датацентр_ у амазона вообще нет, потому что в этом месте things get complicated ;)
Следует помнить, что речь идёт о школе вообще, а не о школе программистов. Зачем экономистам, юристам, литераторам, художникам, артистам, и прочим из этой серии нужно знать про какие-то там указатели?
В некотором роде, язык программирования в школе вообще лишний. Там должна идти речь о работе с техникой и информацией как таковой, а азы программирования лишь на уровне понимания насколько всё сложно и почему в этом мире всё поголовно кривое.
Позовите когда Авраам будет рожать Исаака, Иакова, Иуду и братьев его параллельно за 1 человекомесяц — такие проблемы гораздо ближе к реальности и меня интересует как другие их решают.
Мне как раз наоборот: нужна легко изменяемая структура, а ещё лучше мульти-структурность, а сопутствующие потери производительности готов покрывать масштабированием; ну и плюс не хочу привносить лишних человеческих компетенций (читай, С/С++) без нужды.
А неструктурированные данные, в принципе, поддерживаются почти везде. Это как раз не проблема — можно и эмулировать через текстовое поле.
Про redis, кстати, читал замеры — он выдаёт много (3-5-10K/sec — забыл) только на push-операциях; а вот на pull он такой же медленный как и все остальные (1-2К/sec).
Вопросы: Не пробовали ли? Не примеряли ли? Как и почему подходит или не подходит? Мне на среднюю перспективу тоже нужна реал-таймовая система обработки большого потока событий, вот и смотрю на чужие опыты на этой полянке.
Но, как говорится, уже поздно. На gmail-аккаунт навешано много контактов, и теперь их надо перекидывать на свой доменный аккаунт. И никаких утилит по слиянию гугло-профайлов, размеется, нет — всё ручками. Эх, гугл, гугл…
Рассчитана ли ваша система на гетерогенность в плане языков/фреймворков? Например, если в какой-то момент через 2-3-4 года вы поймёте, что python-программистов на рынке стало больше и они лучше, чем php, а скорость обработки запросов в pypy в N раз выше чем в php. Или в результате коллективного умопомрачения мирового масштаба все начнут использовать Java/NodeJS/Go/ещё-что-нибудь. Не суть важно почему.
А выводы каждый делает для себя сам. Там описаны мои. Будущие покупатели HTC пусть делают свои.
В каком месте там бред, кстати? Уточню и поправлю. Заранее спасибо.
А по делу: когда я говорил что ненадёжно, я имел в виду что реально ненадёжно. Если эти «костыли» кривят NTFS, то родименький chkdsk может всё поправить. Или там, если диск внезапно теряет питание (вынут из USB) в процессе записи мета-инфы.
А вот если такая жопа — сбой записи или кривые костыли (exFAT, кстати, тоже прориетарная от MS и подлежит лицензированию (сюрпрайз! сюрпрайз!), так что в линуксах будет очередной «костыль») — так вот, если жопа случается на exFAT — то всё, никакой chkdsk не поможет, так как копия таблицы только одна и она повреждена. Данные (все или частично) утеряны где-то там в секторах. Причём это бабка надвое сказала что только свежие данные; могут и случайные из старых.
NTFS-3G работает медленно. Скорость записи у меня была порядка 3 MB/sec. Есть решение с родными драйверами — с ними скорость записи порядка 30 MB/sec. См тут или тут.
Раньше было проще, да. Амнистии всякие. Знал бы куда упаду — соломку бы подстелил, как говорится.
Да, придётся ждать. Я, конечно, это имею в виду, когда ищу. Ну и там есть ряд исключений: если работодатель на территории кампуса университета, то лимит не действует. Но я таких не встречал; все по городам, в основном.
Доступ к профессиональным трудовым рынкам будет сразу закрыт. Только полы подметать, в лучшем случае.
Впрочем, особой скромностью я не страдаю. Хотя вот какие-то конкретные аспекты, скорее даже местные ритуалы может и упускаю из виду.
Да, поэтому я радуюсь что хотя бы хотят. А что не берут — значит всё-таки выгляжу недостаточно гениальным, чтоб ради меня помучаться с бюрократией. Если точнее, помучаться может и юрист; а вот ждать… Сам запрос на H1b там — 2 недели в премиум-режиме. Подготовка рабочего места для приёма иностранного работника (которая не с миграционным, а с трудовым ведомством) — вот не уверен тут, разные версии есть, от пары недель до пары месяцев.
А вот, коль уж 4 года работаете, расскажите как тут искать работу программисту? А то что-то как-то никак не получается. Всё вокруг да около, хотят да не берут. Пытаюсь понять что я делаю не так.
Для пущей ясности:
образ — snapshot
том — volume
Хочу вас слегка поправить: по всей статьей использована неправильная терминология. У амазона есть несколько _регионов_ (вот те 5 штук), которые делятся на примерно 2-3 _зоны_доступности_ в каждом регионе. Термина _датацентр_ у амазона вообще нет, потому что в этом месте things get complicated ;)