Я на ATTINY-85 делал FFT 8bit с целочисленным LUT для sin/cos и она занимала памяти совсем чуток (нужно только до 45 градусов хранить) причём одна и для sin и для cos - все выводится отлично на ходу - вообще никаких проблем.
Ради такого и читаешь хабр, жаль редко появиляются статьи такого уровня.
Спасибо вам за отличный материал от человека, который когда-то писал свой собственный сниффер на базе WinPCap-а и даже написал, но давно уже все забыл )
Самый главный вопрос остался не раскрыт - какая механика у замка?
Просто защёлка? Или ригель реально закрывается? Или он просто в виде накладки?
Возможно-ли его установить основным замком на железную дверь? (там запирание обычно в 3 стороны)
Возможно-ли поставить на сувальдный замок, а не на быстро вскрываемый английский?
Все что-то про электронную безопасность, ок, а что с механикой?
P.S. для гостиниц выпускаются достаточно дешёвые защелки - соленоид и ригель внутри - этакий электронный шпингалет, покупали его по 16$ за штуку включая исполнитель на ESP (wifi/ble) - для надежного закрытия не подойдёт, для суточных/гостиниц - вообще отлично (ключи от основного замка в квартире/номере, защёлка используется при заселении).
Главная проблема в том, что подход "пропсы вниз - сообщения вверх" придуманы не просто так, а чтобы не распутывать потом клубок "кто-же где-же таки изменил эту переменную?!"
По-этому, ИМХО (и собственно так в официальной документации) - инжектить любую переменную нужно через readonly вместе с методом, который может эту переменную изменять, и в компоненте не изменять данную переменную напрямую, а использовать метод. Это реально уберегает от очень многих головняков (хотя бы потому, что для простой отладки будет достаточно добавить в данный метод печать трейса, чтобы понять "кто-же где-же").
Исключения, естественно, есть - очень тесно связанные компоненты и не более одного уровня (т.е. родитель-ребенок). Например табы (родительский холдер и его дети, собственно, сами табы). Но и там, чтобы не плодить "везде делаем так, а вот здесь можно не так" и поддерживать некоторую гомогенность системы, я бы все сделал через readonly + метод.
Вы требования их сервера синхронизации видели? Если не видели - посмотрите.
Это даже не стрельба гаубицей по воробьям - там можно целый сервис высокнагруженного бизнеса на этом решении организовать, а не то что файл конфигурации синхронизировать.
Нужна нормальная база данных, а не колхоз с файлом.
Расскажите это SQLlite-у, который, собственно, в Mozilla-вских продуктах широко используется.
Достаточно положить один файл SQLite, и выполнять синхронизацию от любого кол-ва устройств.
Да и, честно, вообще проблем сделать это хоть с одним файлом с JSON ни каких нет - с помощью блокировок все это решаемо. Конфликт может быть только при обновлении.
При синхронизации заблокировал (остальные ждут освобождения), синхронизировал, разблокировал - все - будет работать вполне нормально, без каких-либо конфликтов.
Как сделать сигнал блокировки - можно атрибутами файла, переименовыванием, созданием лок-файла рядом - вариантов также масса.
Есть только один риск - если приложение упало не разблокировав файл - решается временной меткой файла - если с момента блокировки прошло достаточно много врмени, форсить разблокировку-блокировку.
Чтобы было подобие транзакционности и избежать неконсистентности делают так: блокируют основной файл, пишут файл рядом, переименовывают записанный файл в основной файл, снимают блокировку. Это обеспечивает консистентность.
Больше всего задалбывают те, кто начинает критиковать, не разобравшись,
Я, как раз, разбирался - и то, что там предлагают - нормально не юзабельно. Я решил это проблему самописным экстеншеном (синхронизация закладок/открытых вкладок - мне больше ничего не надо), но да - с бд на своем собственном сервере, так как она уже там была. Мог сделать и через один файл.
Прежде чем навшивать ярлыки на собеседника, может быть стоило поинтересоваться его опытом?
А если серьезно - то задолбали бесполезные изменения аля "нововведения" и попытки затащить пользователей к себе.
Понятно почему очень хочется, но хотя-бы в одной альтернативе могли этого не делать или сделать возможность сторить данные в виде одного файла по указанной ссылке - тогда это можно было класть это куда угодно - хочешь - к ним на сервер, хочешь - в дропбокс, хочешь - к себе на vds.
Конечно, технология виновата, а не сами люди. Это-ж технология подкладывает себя людям в игрушки!
А ещё надо запретить жпс-трекеры, сотовые телефоны и фонарики!
Apple недостаточно информирует о технологиях, научные журналы вообще охренели - ничего не понятно, а у людей лапки!!!
Вчера, выходя из бара асфальт стал пониматься и бить поситителей по голове! Нужно, чтобы дорожные службы информировали поситителей, что нельзя так бухать!
Написание кода, именно набор текста, занимает довольно небольшую долю времени погромиста.
Кроме просто написания, это нужно еще продумать.
Компилятор следит.
Компилятор следит за верностью использования, а не за бизнес-логикой, "следить" в этом случае - это использовать согласно задаче, а не в плане правильно/неправильно
Типизация "настраивается" 1 раз, а дальше оно само.
Нет, само оно только подсказывает типы, если они уже написаны, никто за вас автоматом типы в функцию или класс, который еще не написан, как и его составлюящие, не подставит, если он состоит из новых сущностей.
Т.е. программирование таки разделяется на две вещи, как я уже выше писал - создание/изменение типов там где нужно, и сама программа, это использующая , для решения задачи бизнеса.
Грубо говоря, если вам надо описать что-то из чего-то - вы вынуждены будете описать тип того, что хотите в контейнер пооложить, а потом объявить контейнер соответствующего типа. Никто за вас это не сделает. В языка со слабой типизацией вы просто объявили контейнер и кладете туда все что хотите.
И еще раз - мой посыл не в том, что слабая или сильная типизация плохи или хороши, а в том, что они дают разные преимущества.
Оттуда, что не надо описывать дополнительно типы, следить за ними и их использованием.
Кроме того, когда пишешь фии и еще неизвестно что она должна возвращать (POC например) - с этим тоже можно не заморачиваться и дописать позже и тд.
Вобщем как раз из-за того, что при использовании типов ты как бы два рилма в голове держишь - рилм кода бизнес-логики и рилм типов, этот код обслуживающий.
Молоток - очень крутая штука, я реально не понимаю людей, которые используют отвертку! Ведь молотком можно и гвозь забивать и шуруп!
Очередная статья из серии "Кто сильнее Акула или Медведь?".
Это все - инструменты. Умение их использовать открывает вам соответсвующие двери и наоборот.
Правильно настроенный линтер на языке со слабой типизацией сводит практически все описанные ошибки на нет. Скорость разработки POCов или каких-либо конверторов данных для разовых операций идет гораздо быстрее на языках со слабой типизацией - один из сильных вариантов их использования.
Тяжелый проект, сторящийся на века и поддерживаемый командой - да, нужно писать с типизацией - на дает соотвествующую выгоду, расплата за это - время написания кода.
Вот и все - но нет, опять появляются остроконечники vs тупоконечники.
Еще раз - языки - это инструменты, универсального нет - выбирая один, ты всегда в чем-то выигрываешь, а в чем-то проигрываешь.
Справедливости ради, быковать начал как раз другой партнер.
Доказательство чипов-шпионов и тд так и не предоставили. Ну и тп.
Это вовсе не означает, что КНР белый и пушистый, но то, что он сделал и почему - как раз не связано с их быкованием - они достаточно честно себе вели с партнерами, чего не сказать про них. Их мотивы тоже понятны, но вот поведение - не очень.
Ну и не надо китайцев за дураков деражть - они прекрасно мониторят рынок и в случае появления "конкурентов" будет работать старая добрая схема с демпингом.
Те господа импортозамещатели даже не в курсе, что в разных языках слова могут иметь разные оттенки смысла и переводить их "в лоб" не очень хорошо.
P. S. емнип создатели его так назвали держа в голове как раз слэнговый оттенок, который можно на русский грубо перевести так "из искры возгорится пламя", фитиль тут не причём, скорее больше подходит русское слово "растопка", ну или "дрова". То, что понимают у нас под словом "фитиль" проводится на английский как wick. Именно по-этому у меня даже асссоциаций не возникало.
Вот и назвали бы свой сервис "Искра" — оно по смыслy как раз бьется с оттенком слова tinder + на русском есть оттенок этого слова в плане отношений.
Ну или "Фертиль" — было бы по делу, с юмором, отсылкой и на французский манер)
Ответьте пожалуйста на один вопрос — доколе это будет на Хабре? Каждый пост минусуют — вам это ни о чем не говорит?
Попытки высосать техническую составляющую из пальца (или откуда там у вас) в статье выглядят смешно и нелепо.
Одно только ваше название вызывает у людей чуть постарше ассоциацию с одним очень интересным, но далёким от знакомств, журналом — и из-за диссонанса это вызывает раздражение, а помладше даже слова такого не знают, что, в принципе, вполне нормально. Страшно подумать, откуда оно взялось для такого сервиса. У меня только старый анекдот напрашивается про дядьку с животом в бане, бомбу, двух ребятишек и короткий фитиль…
Кроме того, в силу некоторых обстоятельств (которые ведомы большинству, но почему-то неведомы тем, кто пытается "предоставлять" услуги на данном поле) на всех подобных сервисах знакомств всегда много М и очень мало Ж, однако вы упорно пытаетесь постить статьи на ресурсе с точно таким-же перекосом.
Я даже и не знаю, что вам сказать после этого…
ИМХО регистрироваться у вас при таком подходе точно не надо.
BluePill хватит заглаза вместо такого монстра, если уж делать.
Ну это будет стрельба межконтинентальной пушкой по воробьям, но работать, естественно, будет.
Я на ATTINY-85 делал FFT 8bit с целочисленным LUT для sin/cos и она занимала памяти совсем чуток (нужно только до 45 градусов хранить) причём одна и для sin и для cos - все выводится отлично на ходу - вообще никаких проблем.
Ради такого и читаешь хабр, жаль редко появиляются статьи такого уровня.
Спасибо вам за отличный материал от человека, который когда-то писал свой собственный сниффер на базе WinPCap-а и даже написал, но давно уже все забыл )
Е мае! С возвращением! Ну и как всегда - божественно! Даже для такого человека, как я, который рисовать толком не умеет, только обрабатывать)
Как и те, кто украли ваш телефон и пришли с ним по адресу... /sarcasm
Самый главный вопрос остался не раскрыт - какая механика у замка?
Просто защёлка? Или ригель реально закрывается? Или он просто в виде накладки?
Возможно-ли его установить основным замком на железную дверь? (там запирание обычно в 3 стороны)
Возможно-ли поставить на сувальдный замок, а не на быстро вскрываемый английский?
Все что-то про электронную безопасность, ок, а что с механикой?
P.S. для гостиниц выпускаются достаточно дешёвые защелки - соленоид и ригель внутри - этакий электронный шпингалет, покупали его по 16$ за штуку включая исполнитель на ESP (wifi/ble) - для надежного закрытия не подойдёт, для суточных/гостиниц - вообще отлично (ключи от основного замка в квартире/номере, защёлка используется при заселении).
Зачастую люди не готовы слышать то, что не хотят услышать. Как-то так.
Проверено.
По-этому Таро, Гадалки, УспешныйУспех и всякая другая жесть в разы популярней, чем поход к человеку/компании, разбирающихся в теме.
Главная проблема в том, что подход "пропсы вниз - сообщения вверх" придуманы не просто так, а чтобы не распутывать потом клубок "кто-же где-же таки изменил эту переменную?!"
По-этому, ИМХО (и собственно так в официальной документации) - инжектить любую переменную нужно через readonly вместе с методом, который может эту переменную изменять, и в компоненте не изменять данную переменную напрямую, а использовать метод. Это реально уберегает от очень многих головняков (хотя бы потому, что для простой отладки будет достаточно добавить в данный метод печать трейса, чтобы понять "кто-же где-же").
Исключения, естественно, есть - очень тесно связанные компоненты и не более одного уровня (т.е. родитель-ребенок). Например табы (родительский холдер и его дети, собственно, сами табы). Но и там, чтобы не плодить "везде делаем так, а вот здесь можно не так" и поддерживать некоторую гомогенность системы, я бы все сделал через readonly + метод.
Вы требования их сервера синхронизации видели? Если не видели - посмотрите.
Это даже не стрельба гаубицей по воробьям - там можно целый сервис высокнагруженного бизнеса на этом решении организовать, а не то что файл конфигурации синхронизировать.
Расскажите это SQLlite-у, который, собственно, в Mozilla-вских продуктах широко используется.
Достаточно положить один файл SQLite, и выполнять синхронизацию от любого кол-ва устройств.
Да и, честно, вообще проблем сделать это хоть с одним файлом с JSON ни каких нет - с помощью блокировок все это решаемо. Конфликт может быть только при обновлении.
При синхронизации заблокировал (остальные ждут освобождения), синхронизировал, разблокировал - все - будет работать вполне нормально, без каких-либо конфликтов.
Как сделать сигнал блокировки - можно атрибутами файла, переименовыванием, созданием лок-файла рядом - вариантов также масса.
Есть только один риск - если приложение упало не разблокировав файл - решается временной меткой файла - если с момента блокировки прошло достаточно много врмени, форсить разблокировку-блокировку.
Чтобы было подобие транзакционности и избежать неконсистентности делают так: блокируют основной файл, пишут файл рядом, переименовывают записанный файл в основной файл, снимают блокировку. Это обеспечивает консистентность.
Я, как раз, разбирался - и то, что там предлагают - нормально не юзабельно. Я решил это проблему самописным экстеншеном (синхронизация закладок/открытых вкладок - мне больше ничего не надо), но да - с бд на своем собственном сервере, так как она уже там была. Мог сделать и через один файл.
Прежде чем навшивать ярлыки на собеседника, может быть стоило поинтересоваться его опытом?
Mozilla всё :(
А если серьезно - то задолбали бесполезные изменения аля "нововведения" и попытки затащить пользователей к себе.
Понятно почему очень хочется, но хотя-бы в одной альтернативе могли этого не делать или сделать возможность сторить данные в виде одного файла по указанной ссылке - тогда это можно было класть это куда угодно - хочешь - к ним на сервер, хочешь - в дропбокс, хочешь - к себе на vds.
О, дивный новый мир!
Конечно, технология виновата, а не сами люди. Это-ж технология подкладывает себя людям в игрушки!
А ещё надо запретить жпс-трекеры, сотовые телефоны и фонарики!
Apple недостаточно информирует о технологиях, научные журналы вообще охренели - ничего не понятно, а у людей лапки!!!
Вчера, выходя из бара асфальт стал пониматься и бить поситителей по голове! Нужно, чтобы дорожные службы информировали поситителей, что нельзя так бухать!
Как жииить?!!
Кроме просто написания, это нужно еще продумать.
Компилятор следит за верностью использования, а не за бизнес-логикой, "следить" в этом случае - это использовать согласно задаче, а не в плане правильно/неправильно
Нет, само оно только подсказывает типы, если они уже написаны, никто за вас автоматом типы в функцию или класс, который еще не написан, как и его составлюящие, не подставит, если он состоит из новых сущностей.
Т.е. программирование таки разделяется на две вещи, как я уже выше писал - создание/изменение типов там где нужно, и сама программа, это использующая , для решения задачи бизнеса.
Грубо говоря, если вам надо описать что-то из чего-то - вы вынуждены будете описать тип того, что хотите в контейнер пооложить, а потом объявить контейнер соответствующего типа. Никто за вас это не сделает. В языка со слабой типизацией вы просто объявили контейнер и кладете туда все что хотите.
И еще раз - мой посыл не в том, что слабая или сильная типизация плохи или хороши, а в том, что они дают разные преимущества.
Оттуда, что не надо описывать дополнительно типы, следить за ними и их использованием.
Кроме того, когда пишешь фии и еще неизвестно что она должна возвращать (POC например) - с этим тоже можно не заморачиваться и дописать позже и тд.
Вобщем как раз из-за того, что при использовании типов ты как бы два рилма в голове держишь - рилм кода бизнес-логики и рилм типов, этот код обслуживающий.
Надеюсь понятно изложил.
Молоток - очень крутая штука, я реально не понимаю людей, которые используют отвертку! Ведь молотком можно и гвозь забивать и шуруп!
Очередная статья из серии "Кто сильнее Акула или Медведь?".
Это все - инструменты. Умение их использовать открывает вам соответсвующие двери и наоборот.
Правильно настроенный линтер на языке со слабой типизацией сводит практически все описанные ошибки на нет. Скорость разработки POCов или каких-либо конверторов данных для разовых операций идет гораздо быстрее на языках со слабой типизацией - один из сильных вариантов их использования.
Тяжелый проект, сторящийся на века и поддерживаемый командой - да, нужно писать с типизацией - на дает соотвествующую выгоду, расплата за это - время написания кода.
Вот и все - но нет, опять появляются остроконечники vs тупоконечники.
Еще раз - языки - это инструменты, универсального нет - выбирая один, ты всегда в чем-то выигрываешь, а в чем-то проигрываешь.
БОЖЕ!!! Какой ужас! </sarcasm
Справедливости ради, быковать начал как раз другой партнер.
Доказательство чипов-шпионов и тд так и не предоставили. Ну и тп.
Это вовсе не означает, что КНР белый и пушистый, но то, что он сделал и почему - как раз не связано с их быкованием - они достаточно честно себе вели с партнерами, чего не сказать про них. Их мотивы тоже понятны, но вот поведение - не очень.
Ну и не надо китайцев за дураков деражть - они прекрасно мониторят рынок и в случае появления "конкурентов" будет работать старая добрая схема с демпингом.
С Галлием не все так просто.
От оно что! А че не трутовик?)))
Те господа импортозамещатели даже не в курсе, что в разных языках слова могут иметь разные оттенки смысла и переводить их "в лоб" не очень хорошо.
P. S. емнип создатели его так назвали держа в голове как раз слэнговый оттенок, который можно на русский грубо перевести так "из искры возгорится пламя", фитиль тут не причём, скорее больше подходит русское слово "растопка", ну или "дрова". То, что понимают у нас под словом "фитиль" проводится на английский как wick. Именно по-этому у меня даже асссоциаций не возникало.
Вот и назвали бы свой сервис "Искра" — оно по смыслy как раз бьется с оттенком слова tinder + на русском есть оттенок этого слова в плане отношений.
Ну или "Фертиль" — было бы по делу, с юмором, отсылкой и на французский манер)
Ответьте пожалуйста на один вопрос — доколе это будет на Хабре? Каждый пост минусуют — вам это ни о чем не говорит?
Попытки высосать техническую составляющую из пальца (или откуда там у вас) в статье выглядят смешно и нелепо.
Одно только ваше название вызывает у людей чуть постарше ассоциацию с одним очень интересным, но далёким от знакомств, журналом — и из-за диссонанса это вызывает раздражение, а помладше даже слова такого не знают, что, в принципе, вполне нормально. Страшно подумать, откуда оно взялось для такого сервиса. У меня только старый анекдот напрашивается про дядьку с животом в бане, бомбу, двух ребятишек и короткий фитиль…
Кроме того, в силу некоторых обстоятельств (которые ведомы большинству, но почему-то неведомы тем, кто пытается "предоставлять" услуги на данном поле) на всех подобных сервисах знакомств всегда много М и очень мало Ж, однако вы упорно пытаетесь постить статьи на ресурсе с точно таким-же перекосом.
Я даже и не знаю, что вам сказать после этого…
ИМХО регистрироваться у вас при таком подходе точно не надо.
Про режим флешки я как раз ничего и не писал)