Better command line argument parsing using D’s powerful compile-time code generation facilities.

Note: This is a stable library, but it is no longer maintained. If you’d like to help out with maintanence please make an issue letting me know!

import std.stdio;
import darg;

struct Options
{
    @Option("help", "h")
    @Help("Prints this help.")
    OptionFlag help;

    @Option("threads", "t")
    @Help("Number of threads to use.")
    size_t threads;

    @Argument("file", Multiplicity.zeroOrMore)
    @Help("Input files")
    string[] files;
}

// Generate the usage and help string at compile time.
immutable usage = usageString!Options("example");
immutable help = helpString!Options;

int main(string[] args)
{
    Options options;

    try
    {
        options = parseArgs!Options(args[1 .. $]);
    }
    catch (ArgParseError e)
    {
        writeln(e.msg);
        writeln(usage);
        return 1;
    }
    catch (ArgParseHelp e)
    {
        // Help was requested
        writeln(usage);
        write(help);
        return 0;
    }

    foreach (f; options.files)
    {
        // Use files
    }

    return 0;
}

$ ./example --help
Usage: example [--help] [--threads=<ulong>] [file...]

Positional arguments:
 file            Input files

Optional arguments:
 --help, -h      Prints this help.
 --threads, -t <ulong>
                 Number of threads to use.

$ ./example --foobar
Unknown option '--foobar'
Usage: program [--help] [--threads=<ulong>] [file...]

MIT License

• 객체지향 설계원칙에 따라 RESTful API 를 설계 합니다.

• TDD개발론을 적용하며, 테스트의 중요성에 대해 학습합니다.

• 대용량 트래픽과 동시성에 대해 고려하며 개발합니다.

• 새로운 커밋이 발생할 때 마다 코드리뷰를 통해 리팩토링이 필요한 부분을 찾아내고, 개선합니다.

구현하고 싶은 기능

사용자가 참여하고 있는 경매 누군가 입찰 했을 때, 경매에 참가한 사용자들에게 새로운 입찰 발생 메시지를 보내고, 접속중인 사용자에게는 실시간으로 알림을 보내는 기능을 구현하고자 했습니다.

문제

• 새로운 입찰 발생 메시지를 보내는 작업은 DB에 접근 해 Insert 쿼리 호출 해야하고, 실시간 알림을 발송하기 위해 Websocket 을 사용해 접속한 대상을 체크해 알람을 보내야 했습니다. 경매 참여자가 증가할 수록, 입찰 로직 수행시간 보다 메시지와 실시간 알림을 보내기위한 대기시간이 길어졌습니다.

해결방안 및 결과

• 경매 참여자가 많아질 경우에도 입찰 로직의 수행시간을 보존하고자 멀티모듈을 활용, 입찰 로직을 수행하는 서버와 경매 알림 로직을 수행하는 서버를 분리해 수행하도록 했습니다.
  • 경매 참여자가 많아질 경우에도, 경매 등록 로직은 100ms 이내로 수행될 수 있습니다.
  • 핵심 로직(경매) 이외 문제가 발생하더라도, 메인서버의 안정성을 보장할 수 있습니다.
  • 서버 확장이 필요할 때, 트래픽이 몰리는 특정 서버에 대해서만 확장이 가능해 비용 효율성을 높일 수 있습니다.
  • 기능변경 및 개선 작업이 이루어질 때, 다른서버에 미치는 영향을 최소화할 수 있습니다.

문제

• 한 가지 기능을 위해, 여러개의 서버에서 작업이 이루어져야 했습니다.
• 서버가 물리적으로 결합되어 있어, 외부에서 서버의 구조를 파악할 수 있었습니다.
• 서버가 다운되거나 많은 요청이 몰리더라도, 메시지 손실이 발생할 수 있었습니다.

해결방안 및 결과

• 서버의 연결을 메시지 큐(AWS SQS)를 통해 발행, 구독 하도록 했습니다.
  • 여러 서버에서 작업이 비동기적으로 이루어 질 수 있어, 시스템의 처리량을 증가시키고 사용자에게 빠른 서비스를 제공할 수 있습니다.
  • 각 서버가 물리적 결합이 아닌 간접적으로 통신되므로, 외부에서 구조를 파악할 수 없게 해 보안적으로 안전하게 유지할 수 있습니다.
  • 서버가 다운되거나 많은 요청이 몰리더라도, 큐를 통해 메시지가 관리되어, 메세지 손실 없이 안정적으로 처리할 수 있습니다.

• ECS Fargate를 이용해 Main, Sender, Broker 3개의 서비스를 띄우고, ALB 설정을 통해 /sender/* 로 요청 되는 건에 대해서는 Notification Sender 어플리케이션으로, 나머지 요청은 Main 어플리케이션으로 요청되도록 구성했습니다.

• Redis 서버는 ElastiCache 를 활용하며, Main 서버에서의 로그인 세션 공유, 캐싱처리, 입찰 시 동시성 제어를 위한 Lock 으로 사용하고 있습니다.

• AWS SQS를 활용해 Main 서버와 Broker 서버 간의 메시지 전달, Sender 서버와 Broker 서버 간의 메시지 전달을 구현했습니다.

• 로그인 시, 고객은 Sender 서버와 Websocket 을 통해 연결상태를 유지합니다.

• 고객이 입찰 시, Main 서버에서는 해당 요청을 받아 입찰로직을 수행하고, AWS SQS(sha-message-queue)에 경매 정보 메시지를 Publish 합니다.

• Broker 서버에서는 AWS SQS(sha-message-queue)에 메시지를 받았을 때, 경매 참여자의 메시지함에 메시지를 추가하고, 알람을 위한 정보를 AWS SQS( sha-message-send-queue) 로 Publish 합니다.

• Sender 서버에서는 AWS SQS(sha-message-send-queue)에 메시지를 받았을 때, Websocket 을 통해 실시간 알람을 전송합니다.

• 프로젝트의 역할을 분리하기 위해 멀티모듈을 사용했습니다. 공통적으로 사용되는 기능들을 common 모듈로 구분한 뒤 해당 모듈을 사용해 main과 broker 어플리케이션을 구성했고, 실시간 알람을 위한 Sender는 따로 어플리케이션을 구성했습니다.

• TeamCity 의 VCS Trigger 를 통해 Github Main 브런치의 커밋 이벤트를 감지하고, 해당 이벤트에 대해 빌드 및 테스트를 진행 후 Docker 이미지를 구성해 ECR로 업로드합니다.

• 업로드 된 Docker 이미지를 ECS Fargate 에 배포하고, ALB 를 통해 서비스를 제공합니다.

A toolkit to perform Distributed Denial of Service Attack using windows system, for which I designed a worm that embeds into windows startup upon it’s first trigger. And then after will automatically start whenever the system is turned on.

• It’s really simple to start with, just go ahead and clone the repository on a windows machine.
• Now configure your PHP server from where you can keep an eye on systems that are infected by this Worm.
• Do copy all the php files in server directory to suitable hosted directory on your server.

• Now run zombie.cpp in any suitable C++ compiler.
• Do remember to replace SERVER_URL macro definition with link of your server.
• This will register zombie executable file to startup folder making sure that program is triggered upon windows boot.
• This executable can be shared on different windows system and for all these notorious zombies, you have the control.

• The interface is quite simple to use.
• Enter the site you want to attack and ping limit (iterations).
• Woohooo, all your zombies on windows system through out the world are doing nasty stuff for you.
• Soon, if number of live bots are enough, the site will go down.

• A sample version is hosted on here

• Further I want to make the worm more independent.
• It must have cloning and self replicating properties.
• Also encrypt it, making it very difficult to trace.
• And many more mischievous ideas.

• Please feel free to raise issues.
• Pull Requests are utmost welcomed.

The AWS Deployment Framework (ADF) is an extensive and flexible framework to manage and deploy resources across multiple AWS accounts and regions within an AWS Organization.

ADF allows for staged, parallel, multi-account, cross-region deployments of applications or resources via the structure defined in AWS Organizations while taking advantage of services such as AWS CodePipeline, AWS CodeBuild, and AWS CodeCommit to alleviate the heavy lifting and management compared to a traditional CI/CD setup.

ADF allows for clearly defined deployment and approval stages which are stored in a centralized configuration file. It also allows for account based bootstrapping, by which you define an AWS CloudFormation template and assign it to a specific Organization Unit (OU) within AWS Organizations. From there, any account you move into this OU will automatically apply this template as its baseline.

• Refer to the Installation Guide for Installation steps.
• Refer to the Admin Guide on guidance how-to manage and administrate ADF.
• Refer to the User Guide for using ADF to generate and manage pipelines.
• Refer to the Technical Guide if you want to learn more about the inner workings of ADF. For example in case you want to contribute or build on top of ADF.
• Refer to the Samples Guide for a detailed walk through of the provided samples.
• Refer to the Multi-Organization ADF Setup to use ADF in an enterprise-grade setup.

This system can be used in any ordering place, as it uses Queue data structure which follows FIFO sequence with enquing and dequing as main functions.

The purpose of this project is to develop a food ordering system that can be used to transform the traditional ordering system. Generally, in restaurants menu order system is actual provided in menu card format so the customer must select the menu item then the waiter must come and take the order, which is a long processing method. So, I have designed Food Ordering System that displays food items for customers on their available devices such as user phone, Tablet etc. to give input their orders directly by touching.

The system automatically completes data display, receiving, sending, storage of data and analysis. It is providing many advantages as great user-friendly, saving time, portability, reduce human error, flexibility and provide customer feedback etc. This system required large numbers of manpower to handle customer reservation, ordering food, reminding dishes of customer. “Intelligent Automated Restaurant” it is all about getting all your different touchpoints working together connected, sharing information, speeding processes, and personalizing experiences. E-menu is an interactive ordering system with new digital menu for customers.

The digital world is vast, with limitless boundary. And it does not have to make anyone wait. And that’s the very reason, I have decided to make a food ordering system. This is done by using Python. The menu is programmed at backend to be displayed to user. Queue Data Structure is used to take the order and dispatch it to costumers by using First-In-First-Out (FIFO) method. The software generates the bill as well.

Operating System: Windows

IDE(s): Google Collaboratory

Data Structure: Queue

Programming Language: Python

Queue Data Structure is used in this project, due to the real-life depiction of food ordering system. When the customer(user) places an order, he or she must wait to get the order. Order placing is done by enqueue function and dispatchment of order is done by dequeue.

• The time complexity of enqueuing and dequeuing single order item O (1).
• The time complexity of enqueuing and dequeuing multiple order item O(n).

Food ordering software is having many modules, which make the software more efficient and user friendly.

• Main Menu
• Food items
• Drinks item
• Desserts
• Check cart
• Payment
• Exit

This software can be used in any part of food industry such as:

• Hotels
• Restaurants
• Mess
• Canteens
• Grocery stores
• Food store

Following section describe the work that will be implemented with future release of the software:

• Customize orders: Allow customers to customize food order.
• Enhance user interface by adding more user interactives futures: Provide deals and promotional offers, Provide recipes of the day.
• Payment options: PayPal, Gifts cards etc.
• Delivery option.
• Visual graphical order status bar.
• Show only active order to employees.
• Restaurant locator.

[MyHouse]

• Collect data from a number of sensors by leveraging a simple to customize plugin-based architecture
• Automatic calculation of hourly and daily minimum/maximum/average values for each sensor
• Fully customizable web interface with mobile support to display the sensors’ statistics, control actuators and present custom data
• Natural-language interactive Slack bot for remotely retrieving any statistic, send commands or just having fun
• Speech recognition and text-to-speech capabilities for realtime voice interaction
• Alerting module generating e-mails or Slack notifications whenever a configured condition is met
• Daily e-mail digests containing all the UI widgets configured for the requeted module

Think of myHouse as a framework for automating your house. The first step is to configure the sensors you want to collect data from. Included in the package, there are already a number of plugins (e.g. to collect weather statistics, information from the linux box when it runs, retrieving images from the Internet, your GPS position from icloud, data collected by Wirelessthings/Ciseco sensors, interacting with the GPIO, leveraging rtl_433, etc.) and you can easily add your own plugins.
Once your sensors are configured and data has been collecting, the suite automatically calculates for every hour and for every day minimum/maximum/average values so to present only summarized information without overloading with unnecessary data.

What will be presented in the web interface is completely up to you. You can define your own modules, chose your icons and configure all the widgets that will be presented in the order you like the most. The statistics elaborated by the tool can be presented in a number of ways: timeline charts for different group of sensors with recent or historical data, current measures and minimum/maximum values for today and yesterday are just some of the examples. From the interface your actuators can be controlled as well: thanks to input fields, switches and a fully-featured scheduler, you can meet easily whatever requirements you might have.

Collecting and presenting statistics is nice but you may want to be automatically alerted whenever a specific situation is taking place. This is why you can easily create rules which will trigger when the set of conditions you have defined will be all true. Actions can be configured as well to e.g. send a message to an actuator or just set the value of a sensor. An alert does not necessarily represent a critical situation but can be just a simple messages (e.g. the minimum and maximum temperature we had yesterday indoor) to share with the users. Notificationscan be presented within the web interface, sent by e-mail or sms, sent to a speacker or posted on a Slack channel of your choice.

If you don’t know what Slack is, have a look at it. This collaborative, real-time messaging tool can become your family’s virtual place when enhanced by myHouse. Not only myHouse’s Slack bot will notify the members when something is happening but allows direct interaction in your natural language. Depending on your questions and what the bot knows (e.g. the attached sensors and configured widgets), it can reply by sharing with you its statistics and charts or send commands to an actuator on your behalf. The same mechanism applies if you connect a speaker and a microphone to the station: the bot will be able to understand your requests and respond accordingly.

Since myHouse is a framework, everything is defined in the configuration file so my instance may look completely different than yours. This is nice because allows great flexibility but requires a starting point if you don’t want to get lost in the configuration. For this reason, I’m making my own configuration part of the distribution package under the name config-advanced.json: most of the modules and rules are disabled since do not necessarily work in your environment but at least you have a fully working example to take inspiration from.
In my own myHouse, I have configured the following sensors:

• Pressure, temperature, ambient light and humidity from Wirelessthings/Ciseco sensors
• Forecast, weather condition, temperature, wind, rain/snow from Weather Underground
• Weather alerts from Weather Channel
• GPS position of the family’s members from icloud
• Snapshots from multiple indoor and outdoor webcams
• A number of system statistics from the raspberry pi hosting the application
• Radio sensors from my legacy alarm system using rtl_433
• A PIR sensor attached to the raspberry GPIO
• Earthquake events from usgs as well as our local entity

I have configured then the following modules and widgets:

• Dashboard
  • A selection of the most interesting widgets from the other modules
• Outdoor:
  • Forecast of the next 5 days, temperature ranges, weather conditions, chance of rain and snow
  • External temperature summary with current weather condition, minimum/maximum of today, yesterday, record and normal temperatures
  • External temperature recent (with hourly minimum/average/maximum) and historical (with daily minimum/average/maximum) timeline with weather condition
  • Historical precipitation timeline
  • Wind current measure, summary of today/yesterday, recent and historical timeline charts
  • Humidity current measure, summary of today/yesterday, recent and historical timeline charts
  • Ambient Light current measure, summary of today/yesterday, recent and historical timeline charts
  • Pressure current measure, summary of today/yesterday, recent and historical timeline charts
• Indoor:
  • Internal temperature summary, minimum/maximum of today, yesterday for each room
  • Internal temperature recent (with hourly minimum/average/maximum) and historical (with daily minimum/average/maximum) timeline
  • Humidity current measure, summary of today/yesterday, recent and historical timeline charts
  • Fridge and refrigerator current temperature, summary of today/yesterday, recent and historical timeline charts
  • Battery status of the different sensors
• Webcams:
  • Internet webcams as well as webcams I have indoor and outdoor
• Location
  • Map with the GPS location of all the members of the family automatically generated by leveraging the “Where is my iphone?” API
• Earthquakes
  • Map with relevant earthquakes collected from multiple sources
• Boiler
  • Boiler status, manual switch to power it on/off and target temperature to reach while on
  • Calendar to schedule when the boiler has to automatically turns on and off
• Irrigation
  • Irrigation status, manual switch to turn it on/off in each zone
  • Calendar to schedule when the irrigation has to automatically turns on and off
• Alarm
  • Alarm status and manual switch to arm the system which is automatically set to the status of the physical alarm main unit
  • PIRs, smoke detectors, gas detectors, magnetic sensors. Each sensor can be armed indivirually and reports the last time it has triggered
• System Status:
  • CPU current measure, summary of today/yesterday, recent and historical timeline charts
  • Memory current measure, summary of today/yesterday, recent and historical timeline charts
  • System load current measure, summary of today/yesterday, recent and historical timeline charts
  • Network Connections and services current measure, summary of today/yesterday, recent and historical timeline charts
  • Raspberry’s current temperature, summary of today/yesterday, recent and historical timeline charts
  • Database size current measure and historical timeline chart
• Local Network:
  • Dnsmasq DHCP current leases, static DNS and DHCP mapping (my raspberry acts as a DNS/DHCP server)
• Log Analysis:
  • Daily Logwatch output
• Reboot/shutdown:
  • To reboot or shutdown the raspberry pi hosting the application
• Logs:
  • myHouse logs and system logs
• Configuration:
  • myHouse configuration module

I have finally configured the following rules:

• Outdoor module:
  • Weather alerts
  • Yesterday maximum/minimum temperature above or below the record for that day or the expected normal temperature
  • Yesterday maximum/minimum/average temperature the lowest/highest of the last few days
  • Forecast weather for tomorrow
• Indoor module:
  • Yesterday maximum/minimum/average temperature the lowest/highest of the last few days
  • Temperature inside too high or too low
  • Fridge/Refrigerator temperature too high
  • Flood alert
• Earthquake module:
  • A strong or close earthquake taking place
• System module:
  • CPU utilization/System load/temperature too high
• Boiler module:
  • Turning the boiler on/off when scheduled, requested, or when the indoor temperature is too low/high
• Irrigation module:
  • Turning the irrigation on/off when scheduled
• Alarm module:
  • Arm/disarm the system when the main legacy unit is armed/disarmed, notify when an armed sensor has triggered while the alarm is armed

I have eventually configured a number of rules without conditions (that are used by the bot for its basic knowledge) reporting upon current weather conditions, temperature, boiler status, etc.

• Unzip the package and move its contents to a directory of your choice on your raspberry Pi (e.g. /opt/myHouse)
• Run the installation script as root (e.g. sudo python /opt/myHouse/install.py) which will:
  • download and install all the required dependencies
  • create a service script, copy into /etc/init.d/myHouse and configured it to start at boot time
  • start the service
• Access the web interface (e.g. http://your-raspberry-pi.ip)

Installation logs will be made available under logs/install.log

• Run as root the installation script with the “-u” parameter (e.g. sudo /opt/myHouse/install.py -u) which will:
  • stop the service
  • remove the service script from /etc/init.d/myHouse

The dependencies, the database and all the other files belonging to myHouse will NOT be deleted.

• Stop the service
• Copy the files of the new version in the directory where myHouse is installed, overwriting the existing files or run git pull if you had cloned the repository
• Run as root the install.py script which will install the missing dependencies
• Run as root the upgrade.py script which will upgrade your config.json file
• A backup copy of the configuration file and the database will be saved under the tmp directory
• Start the service

The entire configuration of the suite is within the config.json file, of course in a JSON format (http://www.json.org/). If the file does not exist, at the first run, myHouse will automatically create one as a copy of config-example.json. This is a working example with basic functionalities.

For a more complex example, the one described in the section above, review the config-advanced.json and take inspiration from there to understand the most complex capabilities of myHouse.

The configuration itself is pretty articulated this is why it is highly recommended to review the config-schema.json file for a detailed explanation of the different options and combinations available. Alternatively, the configuration editor available from within the web interface allows to build your own configuration graphically (upon saving, a copy of the previous configuration is stored into the config.bak file). Either way, the resulting file is checked against the schema to ensure the configuration is correct upon startup. A service restart (e.g. sudo /etc/init.d/myHouse restart) is required to apply any change.

The logic behind the configuration file is pretty simple: there is a generic configuration first (where the database is, what is the mailserver, which recipient to send notifications to, how to connect to Slack, what and where to log, etc.) followed by a number of custom modules. Each module is an entry in the menu of the web interface and has three main sections:

• sensors: array of sensors belonging to the module. Each sensor includes the following information:
  • a group ID, sensors belonging to the same group can be presented within the same widget
  • a data structure to instruct the plugin to retrieve the data for the sensor, including the polling interval
  • a set of chart series (highcharts properites) that will be used when representing the chart in the web interface
• widgets: array of rows and widgets to be presented when the user clicks on the module within the web interface. Each widget is described by:
  • a size (up to 12 “slots” are available for each row)
  • a layout, e.g. multiple components within the same widgeta. The most common components are:
    • sensor_group_summary: generate a chart with min/max for each sensor of the specified group for today and yesterday
    • image: add an image from a sensor
    • map: generate an interactive map based on the data of a sensor
    • sensor_group_timeline: generate a chart with a timeline of the given timeframe for the sensors belonging to the given group
    • chart_short/chart_short_inverted: generate a chart with a limited size with the data from a single sensor
    • current_header: generate a header with the current measure of a sensor and an icon
    • current_measure: generate a box with the current measure of a sensor
    • alerts: generate a table with all the alerts generated by the platform
    • checkbox: generate a checkbox controlling the given sensor
    • input: add an input form controlling a given sensor
    • separator: add a line separator
    • configuration: add the configuration editor
    • calendar: add a graphical scheduler storing information in a given sensor
    • data: add raw data from a given sensor
    • table: add a table and format data from a given sensor
    • clock: add an analog clock with the current time –
• rules: array of rules for notifying when a given condition is met. When no condition is specified, the rule will be used by the “oracle” for responding to interactive requests. Each rule is described by:
  • a set of definitions of the data that will be used within the conditions. Each definition extracts from the database one or more values from a given sensor (e.g. yesterday’s average temperature as the latest value of the daily average measures of the outdoor sensor).
  • a set of conditions for comparing dataset defined in the definitions section. All the conditions must be true to have an alert triggering
  • a severity of the alert
  • an time interval for evaluating the conditions (e.g. daily, hourly, every minute, never, etc.)
  • the text of the alert with placeholders from the definitions which will be replaced by the current values

Each plugin can support input (retrieve data from a sensor), output (send data to an actuator) or both.
For input, data can be retrived in two ways: pull (the sensor is pulled at regular time intervals) or push (the plugin is kept running and when a new measure is received, the main engine is notified). The following out of the box plugins are part of the software:

• wunderground: retrieve from Weather Underground the requested measure (e.g. temperature, pressure, weather condition, forecast, etc. review config-schema.json for the full list):
  • request a valid API key from https://www.wunderground.com/weather/api/
  • set the latitude/longitude in the global plugin configuration or within each plugin settings
• weatherchannel: retrieve from Weather Channel weather alerts:
  • set the latitude/longitude in the global plugin configuration or within each plugin settings
  • create a rule to be alerted when the latest weather alert is not empty
• ** messagebridge**: listen for updates from Wirelessthings/ciseco sensors and read the measure of the configured node:
  • the is no polling interval to configure for this plugin since updates are sent real-time by the wirelessthings messagebridge component.
  • it can also instruct Generic IO firmware to sleep when awake
  • can be used to send messages to a sensor
  • ensure messagebridge is running (https://github.com/WirelessThings/WirelessThings-LaunchPad)
• csv: parse a csv file
  • it can be used for parsing custom csv files
• image: retrive an image
  • the image can be either retrived either from a URL or by running a command
  • basic HTTP authentication is supported
  • can be used to retrieve snapshots from the attached raspberry webcam
• icloud: retrive from icloud the location of an IOS device:
  • run python plugin_icloud.py –username=youricloudemail@email.com to configure the plugin and store the icloud password within the keystore first
  • if family sharing is set up (https://support.apple.com/en-us/HT201060) you will have visibility over all the devices
  • a list of devices to display can be configured
  • The data retrieved can be represented with a “map” type widget. The current position as well the tracking of the last few coordinates will be shown
• command: execute a command on the raspberry pi to poll a sensor:
  • can be used to poll sensors directly attached to the GPIO of the raspberry pi
• system: retrieve a system statistic from the raspberry pi:
  • can be selected among a list of pre-defined measures (review the config-schema.json for the full list)
• rtl_433: run rtl_433 in the background and look for a specific sensor from its output to retrieve a measure
  • rtl_433 turns a Realtek RTL2832 based DVB dongle into a 433.92MHz generic data receiver
  • rtl_433 must be installed from https://github.com/merbanan/rtl_433
  • the device must support a json output
• gpio: Interact with the raspberry’s GPIO to capture input from the configured pins or send output signals
  • an input pin can be either periodically polled or can automatically trigger when a high/low edge is detected
• earthquake: retrieve earthquake events from a Federation of Digital Seismograph Network Web Service node
  • Filters can be defined to retrieve only the relevant events
• mqtt: connect to a mqtt gateway and subscribe for topics.
  • The gateway can be either local or remote
  • can send messages to the gateway
• ads1x15: retrieve measures from an attached analog to digital converter ads1x15
  • both ADS1115 and ADS1015 are supported
  • output can be the raw measure, a percentage or a voltage
• dht: retrieve temperature and humidity from an attached DHT11 and DHT22 sensors
• ds18b20:retrieve the temperature from an attached ds18b20 sensor
• rss: retrieve news headlines from a RSS feed
• mysensors: act as a controller to interact with a MySensors (https://www.mysensors.org) gateway and sensors.
  • support multiple serial, ethernet or mqtt gateways
  • support all S & V types
  • support node id generation
  • support smart sleep (outgoing messages are queue and sent to the sensor only once reporting awake)
• bluetooth: allow polling data from BLE devices.

For input, “Push” plugins must implement a “run()” method (which will be called at startup to keep the plugin running in background) and a “register(sensor)” method (for registering suitable sensors against the plugin). When a new measure is available, it must call the “store” method of sensors.py to save the data.
“Pull” plugins must instead implement a “poll(sensor)” method (to retrieve the raw data from the sensor), a “parse(sensor,data)” method (to parse the raw the data previously polled) and optionally a “cache_schema(sensor)” method to cache raw data so preventing different sensors to poll for the same data concurrently. The main engine will be responsible to periodically invoke poll and parse and hence storing the new measure.
For input plugins, they must implement a “send(sensor,data)” that will be invoked to send a message to their supported actuators.

The notification subsystem allows the user to communicate with myHouse and viceversa. Each module can support input (the user requests something to the system), output (the system sends the user a notification) or both.
The following out of the box modules are part of the software:

• email: an email message is sent whenever an alert triggers. Requires a SMTP server configured
• sms: a SMS message is sent whenever an alert triggers. Requires a Betamax-compatible voip service configured
• slack: a slack notification is sent whenever an alert triggers. A slack bot connects to a configured team and channel and allows realtime interaction
• audio: an audio notification is sent to the attached speaker whenever an alert triggers. If a microphone is attached to the system, the user can interacts with it with realtime questions and answers.
• buzzer: play a tone to an attached active buzzer.
• GSM sms: a SMS message is sent through an attached GSM module whenever an alert triggers
• GSM call: a phon call (ring) is placed through an attached GSM module whenever an alert triggers

For each output notification the following can be optionally set:

• a minimum severity: only notification with that severity or more critical will be sent through the channel (e.g. send a sms only for critical alerts)
• a rate limit: maximum number of notifications per hour through that channel (e.g. send maxium 2 sms per hour)
• a “silent” timeframe: a timeframe in which notifications will be muted (e.g. do not send audio notifications during the night)
• a minimum severity for the “silent” timeframe: only notification with that severity or more critical will be sent through the channel when muted (e.g. audio notifications are muted during the night but critical alerts will be sent through this channel anyway)

There are thousands of home automation suites around and dozens of new solutions made available every single day. So why yet another piece of software? I may have very peculiar requirements but none of the products around had a good fit for me.

First, I didn’t want to use a cloud-based service both for privacy reasons and because my Internet connection is not necessarily always on so I had the need to both store and present data from within my network.

Secondarily, I need to review the statistics collected mostly when I am not at home: this is why I had to exclude all the solutions which are creating charts with all the raw data collected if I wanted to avoid high latency and mobile roaming charges. Much lighter and more resistant to spikes looked to me to calculate average/minimum/maximum values for each hour and for each day.

I also wanted a way to centralize in a single place both the sensors and the webcams, independently of the source. This is why this plugin-based architecture: if you are collecting the external temperature from an Internet service and you add a sensor at home to do the same later, you want to keep the history and use the same presentation format. For the same reason I wanted to be indipendent from the different standards and IoT vendors around.

I also wanted to create something adapting easily to the extreme flexibility needed by this kind of solutions. This is why everything is defined in the configuration, the sensors you want to collect data from, the widgets to present in the web interface, the way you want each chart to be drawn.

I also have the need to receive when I’m not at home a very detailed e-mail summary containing the same information as I was browsing the web interface.

For the same reason (and because I dont’ not want to expose the web interface over the Internet so making the access via the VPN not very handy) I wrote the Slack bot. It allows me to immediate access any information I need in real-time, interact with the actuators (e.g. my boiler) quicker and remotely and, why not, having some fun by arguing with a real bot.

The last technical requirement I had was to make the solution as lighter as possible (hence Flask instead of Apache/PHP) and gentle with the SD card of my raspberry pi (hence Redis instead of other SQL databases).7

• The documentation is available at the following location: https://sourceforge.net/p/my-house/wiki/
• The Frequently Asked Questions are available at the following location: https://sourceforge.net/p/my-house/wiki/faq
• The forum is available at the following location: https://sourceforge.net/p/my-house/forum/
• Report any bug or feature request at the following location: https://sourceforge.net/p/my-house/tickets/
• Download the latest release from the following location: https://sourceforge.net/projects/my-house/files/

myHouse makes use of the following third-party software components:

• Python for the entire backend, including the following libraries:
  • flask for the webserver (http://flask.pocoo.org/)
  • numpy for calculating the average out of an array of values (http://www.numpy.org/)
  • APScheduler for scheduling all the recurrent tasks (https://apscheduler.readthedocs.io/en/latest/)
  • slackclient for interacting with Slack (https://github.com/slackhq/python-slackclient)
  • simplejson for more detailed json syntax checks (https://simplejson.readthedocs.io/en/latest/)
  • fuzzywuzzy for fuzzy string matching (https://github.com/seatgeek/fuzzywuzzy)
  • pyicloud for interacting with the Applie iCloud service (https://github.com/picklepete/pyicloud)
  • motionless for generating static maps images out of Google Maps (https://github.com/ryancox/motionless)
  • flask-compress to provide gzip compression to flask (https://github.com/libwilliam/flask-compress)
  • jsonschema to validate the JSON configuration file (https://pypi.python.org/pypi/jsonschema)
  • rpi.gpio to interact with the raspberry GPIO (https://pypi.python.org/pypi/RPi.GPIO)
  • rtl_433 fro turning a Realtek RTL2832 based DVB dongle into a 433.92MHz generic data receiver (https://github.com/merbanan/rtl_433)
  • mosquitto as a local mqtt gateway (https://mosquitto.org/)
  • Pico TTS for offline text-to-speach
  • OpenCV for image analysis and manipulation (http://opencv.org/)
  • gTTS for online Text-to-Speech via the Google TTS API (https://pypi.python.org/pypi/gTTS)
  • mpg123 for mp3 to wav conversion (https://www.mpg123.de/)
  • SpeechRecognition multi-engines speech recognition library (https://pypi.python.org/pypi/SpeechRecognition/)
  • sox for playing and recording audio files (http://sox.sourceforge.net/)
  • flac for encoding audio files (https://xiph.org/flac/)
  • pocketsphinx as offline speach recognition engine (https://github.com/cmusphinx/pocketsphinx)
  • adafruit DHT library to read the DHT series of humidity and temperature sensors (https://github.com/adafruit/Adafruit_Python_DHT)
  • adafruit ADS1x15 library to communicate with ADS1x15 ADC (https://github.com/adafruit/Adafruit_ADS1X15)
  • OPi.GPIO to leverage Orange Pi Zero’s GPIO (https://pypi.python.org/pypi/OPi.GPIO/0.2.1)
• HTML and Javacript for the frontend, including the following libraries:
  • jQuery for event handling (https://jquery.com/)
  • Bootstrap for enhanced user experience (http://getbootstrap.com/)
  • AdminLTE as the web template (https://almsaeedstudio.com/themes/AdminLTE/index2.html)
  • Highcharts/HighStock for the charts (http://www.highcharts.com/products/highstock)
  • Font Awesome for the icons (http://fontawesome.io/icons/)
  • Bootstrap Notify for on-screen notifications (http://bootstrap-notify.remabledesigns.com/)
  • JSON Editor for the configuration editor widget (http://jeremydorn.com/json-editor/)
  • Touchspin for the input spinner component (http://www.virtuosoft.eu/code/bootstrap-touchspin/)
  • Titatoggle for the checkbox component (http://kleinejan.github.io/titatoggle/)
  • Datatables for the tables (https://datatables.net/)
  • dhtmlxScheduler for the scheduler (https://dhtmlx.com/docs/products/dhtmlxScheduler/)
  • gmaps.js to use the potential of Google Maps in a simple way (https://hpneo.github.io/gmaps/)
• Redis for the database (http://redis.io/)

• v1.0:
  • Weather module with static sensors
• v2.0 (for full changelog: https://sourceforge.net/p/my-house/tickets/queue/v2.0/):
  • Added new plugins and enhanced the existing
  • Re-wrote the entire logic and moved from crontab to a builtin scheduler
  • Added alerter module
  • Web interface customizable in terms of widgets and modules
  • Added logging capabilities
  • Added interactive Slack bot
  • Support for multiple data formats
  • Added configuration wizard
  • Added support for imperial measures and fahrenheit temperatures
  • Added support for actuators
  • Added installation and service scripts
  • Added automatic data expiration from the database
• v2.1 (for full changelog: https://sourceforge.net/p/my-house/tickets/queue/v2.1/):
  • Added a “gpio” plugin to interact with the raspberry’s GPIO for capturing input and sending output signals
  • Added a “rtl_433” plugin to capture measures from generic radio sensor
  • Enhanced the “csv” plugin to support generic csv formatted files
  • Enhanced the “icloud” plugin to display an interactive map and the tracking data of the latest positions
  • Enhanced the rule engine to allow executing the same rule for a set of sensors
  • Consolidated the upgrade script
  • Fixed several bugs
• v2.2 (for full changelog: https://sourceforge.net/p/my-house/tickets/queue/v2.2/):
  • Added speech recognition and text-to-speech capabilities for realtime voice interaction
  • Added an earthquake module with the capability to retrieve earthquake events from multiple sources, plot them in an interactive map and alert when a strong/close event takes place
  • Multi-language support
  • GUI color skins support
  • Ability to detect motion and objects (e.g. faces) in images
  • Added SMS notifications
  • Added support for MQTT
  • Added a news module with the latest headlines from one or more RSS feeds
  • Added a new module for rebooting/shutting down the hosting system
  • Added new sensor-specific plugins: ads1x15, dht, ds18b20
  • Added map tracking options to the icloud plugin
  • Added linear regression statistics
  • Added new UI widgets: configurable button
  • Added per-sensor data retention options
  • Added ability to upload data to a Wundergound PWS
  • Bug fixes and minor enhancements
• v2.3 (for full changelog: https://sourceforge.net/p/my-house/tickets/queue/v2.3/):
  • Added support for MySensors serial, ethernet and mqtt gateways
  • Added support for Bluetooth Low Energy (BLE) sensors
  • Included a simpler, fully working example configuration file
  • Improved installation and upgrade scripts
  • Bug fixes and minor enhancements
• v2.4 (for full changelog: https://sourceforge.net/p/my-house/tickets/queue/v2.4/):
  • Added support for SMS/phone call notifications through an attached GSM module
  • Added support for activating a buzzer when an alert triggers
  • Added support for Orange Pi GPIO
  • Added support for running on a generic debian-based linux distribution
  • Enhanced the scheduler’s flexibility
  • Enhaced the rule-based engine’s capabilities
  • Added additional backup options
  • Bug fixes and minor enhancements

An ergonomic, Shopify API Client for Rust.

• GraphQL API support with automatic data deserialization
• Changelog

This asynchronous example uses Tokio and enables some optional features, so your Cargo.toml could look like this:

[dependencies]
shopify_api = "0.8"
tokio = { version = "1", features = ["full"] }

And then the code:

use shopify_api::*;
use shopify_api::utils::ReadJsonTreeSteps;
use serde::{Deserialize};

#[derive(Deserialize)]
struct Shop {
  name: String,
}

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
  let shopify = Shopify::new("hello", "world", String::from("2024-04"), None);

  let graphql_query = r#"
    query {
      shop {
      name
     }
  }"#;

  let variables = serde_json::json!({});
  let json_finder = vec![ReadJsonTreeSteps::Key("data"), ReadJsonTreeSteps::Key("shop")];

  let shop: Shop = shopify.graphql_query(graphql_query, &variables, &json_finder).await.unwrap();
  Ok(())
}

[dependencies]
shopify_api = "0.89"
tokio = { version = "1", features = ["full"] }
graphql_client = "0.14.0"

query GetShop {
  shop {
    name
  }
}

use shopify_api::*;
use graphql_client::GraphQLQuery;

#[derive(GraphQLQuery)]
#[graphql(
    schema_path = "./graphql.schema.json",
    query_path = "graphql/getShop.graphql",
    response_derives = "Debug"
)]
struct GetShop;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
  let shopify = Shopify::new("hello", "world", String::from("2024-04"), None);

  let shop_info = connector
        .shopify
        .post_graphql::<GetShop>(get_shop::Variables {})
        .await;

  Ok(())
}

• 2024-04

Licensed under MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)

An ergonomic, Shopify API Client for Rust.

• GraphQL API support with automatic data deserialization
• Changelog

This asynchronous example uses Tokio and enables some optional features, so your Cargo.toml could look like this:

[dependencies]
shopify_api = "0.8"
tokio = { version = "1", features = ["full"] }

And then the code:

use shopify_api::*;
use shopify_api::utils::ReadJsonTreeSteps;
use serde::{Deserialize};

#[derive(Deserialize)]
struct Shop {
  name: String,
}

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
  let shopify = Shopify::new("hello", "world", String::from("2024-04"), None);

  let graphql_query = r#"
    query {
      shop {
      name
     }
  }"#;

  let variables = serde_json::json!({});
  let json_finder = vec![ReadJsonTreeSteps::Key("data"), ReadJsonTreeSteps::Key("shop")];

  let shop: Shop = shopify.graphql_query(graphql_query, &variables, &json_finder).await.unwrap();
  Ok(())
}

[dependencies]
shopify_api = "0.89"
tokio = { version = "1", features = ["full"] }
graphql_client = "0.14.0"

query GetShop {
  shop {
    name
  }
}

use shopify_api::*;
use graphql_client::GraphQLQuery;

#[derive(GraphQLQuery)]
#[graphql(
    schema_path = "./graphql.schema.json",
    query_path = "graphql/getShop.graphql",
    response_derives = "Debug"
)]
struct GetShop;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
  let shopify = Shopify::new("hello", "world", String::from("2024-04"), None);

  let shop_info = connector
        .shopify
        .post_graphql::<GetShop>(get_shop::Variables {})
        .await;

  Ok(())
}

• 2024-04

Licensed under MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)

• HackerRank problem documentation provided 📃
• Problems are solved in Python 🐍
• Sample tests and outputs included ✏️

• 12/02/2021: HackerRank Substring
• 12/04/2021: Weighted Substrings
• 12/07/2021: Separate the Numbers
• 12/09/2021: Anagrams
• 12/10/2021: Palindrome Index
• 12/14/2021: Making Anagrams
• 12/21/2021: Sherlock’s Anagrams
• 12/23/2021: Common Child (Longest Common Subsequence)
• 12/30/2021: Bear and Steady Gene (Two Pointers Algorithm)
• 01/05/2022: Sherlock and the Valid String
• 01/07/2022: Min-Cost String Construction
• 01/13/2022: Highest Value Palindrome
• 01/27/2022: Morgan and a String (Greedy Lexical Strings)
• 01/31/2022: Sort
• 02/02/2022: Missing Numbers (Set difference)
• 02/08/2022: Pairs (Greedy technique)
• 02/19/2022: Sherlock’s Balanced Sum (Two Pointers Technique)
• 02/22/2022: Ice Cream Parlor (Greedy/Two Pointers Technique)
• 02/24/2022: Cavity Map (String Manipulation)
• 02/26/2022: Manasa Stone (Sets)
• 02/28/2022: ACM Teams (XOR)
• 03/03/2022: Min Cost Birthday Gifts (Min Cost Greedy)
• 03/04/2022: Time in Words (Dictionaries)
• 03/05/2022: Kaprekar Numbers)