Huginn – Build agents that monitor and act on your behalf


What is Huginn?

Huginn is a system for building agents that perform automated tasks for you online. They can read the web, watch for events, and take actions on your behalf. Huginn’s Agents create and consume events, propagating them along a directed graph. Think of it as a hackable Yahoo! Pipes plus IFTTT on your own server. You always know who has your data. You do.

the origin of the name

Here are some of the things that you can do with Huginn:

  • Track the weather and get an email when it’s going to rain (or snow) tomorrow (“Don’t forget your umbrella!”)
  • List terms that you care about and receive emails when their occurrence on Twitter changes. (For example, want to know when something interesting has happened in the world of Machine Learning? Huginn will watch the term “machine learning” on Twitter and tell you when there is a spike in discussion.)
  • Watch for air travel or shopping deals
  • Follow your project names on Twitter and get updates when people mention them
  • Scrape websites and receive emails when they change
  • Connect to Adioso, HipChat, Basecamp, Growl, FTP, IMAP, Jabber, JIRA, MQTT, nextbus, Pushbullet, Pushover, RSS, Bash, Slack, StubHub, translation APIs, Twilio, Twitter, Wunderground, and Weibo, to name a few.
  • Send digest emails with things that you care about at specific times during the day
  • Track counts of high frequency events and send an SMS within moments when they spike, such as the term “san francisco emergency”
  • Send and receive WebHooks
  • Run custom JavaScript or CoffeeScript functions
  • Track your location over time
  • Create Amazon Mechanical Turk workflows as the inputs, or outputs, of agents (the Amazon Turk Agent is called the “HumanTaskAgent”). For example: “Once a day, ask 5 people for a funny cat photo; send the results to 5 more people to be rated; send the top-rated photo to 5 people for a funny caption; send to 5 final people to rate for funniest caption; finally, post the best captioned photo on my blog.”


Join us in our Gitter room to discuss the project and follow @tectonic for updates as Huginn evolves.

Join us!

Want to help with Huginn? All contributions are encouraged! You could make UI improvements, add new Agents, write documentation and tutorials, or try tackling issues tagged with #help-wanted. Please fork, add specs, and send pull requests!

Really want a fix or feature? Want to solve some community issues and earn some extra coffee money? Take a look at the current bounties on Bountysource.

Have an awesome idea but not feeling quite up to contributing yet? Head over to our Official ‘suggest an agent’ thread and tell us!


Please checkout the Huginn Introductory Screencast!

And now, some example screenshots. Below them are instructions to get you started.

Example list of agents

Event flow diagram

Detecting peaks in Twitter

Logging your location over time

Making a new agent

Getting Started


The quickest and easiest way to check out Huginn is to use the offical Docker image. Have a look at the documentation.

Local Installation

If you just want to play around, you can simply fork this repository, then perform the following steps:

  • Run git remote add upstream to add the main repository as a remote for your fork.
  • Copy .env.example to .env (cp .env.example .env) and edit .env, at least updating the APP_SECRET_TOKEN variable.
  • Run bundle to install dependencies
  • Run bundle exec rake db:create, bundle exec rake db:migrate, and then bundle exec rake db:seed to create a development MySQL database with some example Agents.
  • Run bundle exec foreman start, visit http://localhost:3000/, and login with the username of admin and the password of password.
  • Setup some Agents!
  • Read the wiki for usage examples and to get started making new Agents.
  • Periodically run git fetch upstream and then git checkout master && git merge upstream/master to merge in the newest version of Huginn.

Note: By default, emails are intercepted in the development Rails environment, which is what you just setup. You can view
them at http://localhost:3000/letter_opener. If you’d like to send real emails via SMTP when playing
with Huginn locally, set SEND_EMAIL_IN_DEVELOPMENT to true in your .env file.

If you need more detailed instructions, see the Novice setup guide.


All agents have specs! Test all specs with bundle exec rspec, or test a specific spec with bundle exec rspec path/to/specific/spec.rb. Read more about rspec for rails here.



Try Huginn on Heroku: Deploy (Takes a few minutes to setup. Read the documentation while you are waiting and be sure to click ‘View it’ after launch!)

Huginn works on the free version of Heroku with significant limitations. For non-experimental use, we strongly recommend Heroku’s cheapest paid plan or our Docker container.

Please see the Huginn Wiki for detailed deployment strategies for different providers.

Manual installation on any server

Have a look at the installation guide.

Optional Setup

Setup for private development

See private development instructions on the wiki.

Enable the WeatherAgent

In order to use the WeatherAgent you need an API key with Wunderground. Signup for one and then change the value of api_key: your-key in your seeded WeatherAgent.

Disable SSL

We assume your deployment will run over SSL. This is a very good idea! However, if you wish to turn this off, you’ll probably need to edit config/initializers/devise.rb and modify the line containing config.rememberable_options = { :secure => true }. You will also need to edit config/environments/production.rb and modify the value of config.force_ssl.


Huginn is provided under the MIT License.

Build Status Coverage Status Bitdeli Badge Dependency Status Bountysource

Original URL:

Original article

GitHub pages is now running Jekyll 3

GitHub Pages is now running the latest major version of Jekyll, Jekyll 3.0, and with it, many of the complexities associated with publishing have been further simplified, meaning it’s now easier and faster to publish beautiful sites for you and your projects.

A more intuitive Markdown experience

If you’re familiar with using Markdown to author issues, pull requests, or comments on, writing Markdown for GitHub Pages sites will now be equally as intuitive. Markdown may be the lingua franca of the open source community, but that doesn’t mean that certain regional dialects haven’t emerged over the years. Traditionally, authors have had to choose between several different Markdown engines, each with their own interpretations of how Markdown should work.

Starting May 1st, 2016, GitHub Pages will only support Kramdown, Jekyll’s default Markdown engine. If you are currently using Rdiscount or Redcarpet we’ve enabled Kramdown’s GitHub-flavored Markdown support by default, meaning Kramdown should have all the features of the two deprecated Markdown engines, so the transition should be as simple as updating the Markdown setting to kramdown in your site’s configuration (or removing it entirely) over the course of the next three months.

The highlight zone

GitHub Pages now only supports Rouge, a pure-Ruby syntax highlighter, meaning you no longer need to install Python and Pygments to preview your site locally. If you were previously using Pygments for highlighting, the two libraries are feature compatible, so we’ll swap Rouge in for Pygments when we build your site, to ensure a seamless transition.

Traditionally, highlighting in Jekyll has been implemented via the {% highlight %} Liquid tag, forcing you to leave a pure-Markdown experience. With the Kramdown and Rouge as the new defaults, syntax highlighting on GitHub Pages should work like you’d expect it to work anywhere else on GitHub, with native support for backtick-style fenced code blocks right within the Markdown.

Need for speed

Jekyll 3.0 offers several improvements for previewing and optimizing your site locally. For one, local builds are significantly faster, meaning you can preview your changes in near real time, and with incremental regeneration support (experimental), builds can be even faster still.

Jekyll 3.0 also introduces a liquid profiler. By adding --profile to the build or serve command, Jekyll will analyze your site’s build time, so you can see exactly where things can be sped up, ensuring you spend more time authoring content, and less time waiting for your site to build.

Profiler output

Two additional changes

The Jekyll 3.0 upgrade will introduce two additional changes that may affect a small subset of users:

  1. Jekyll no longer supports relative permalinks. This has been the default since Jekyll 2.0, and is only an issue if you explicitly added relative_permalinks: true to your site’s configuration. Going forward, regardless of your site’s configuration, if you add the permalink directive to a page’s YAML front matter, the path should be relative to the site’s root directory, not the page’s parent.

  2. Starting May 1st, 2016, GitHub Pages will no longer support Textile. If you are currently using Textile (Redcloth) to author your Jekyll site, you’ll need to convert your site to use Markdown instead.

The changes introduced today promise to make GitHub Pages a faster, more intuitive experience for new and power users alike. For more information on upgrading, see Jekyll’s 3.0 upgrade guide, and if you have any questions about Jekyll 3.0, the upgrade process, or just GitHub Pages in general, please get in touch with us.

Happy (simplified) publishing!

Original URL:

Original article

Please stop using Slack for FOSS projects

I’ve noticed that more and more projects are using things like Slack as the chat
medium for their open source projects. In the past couple of days alone, I’ve
been directed to Slack for Babel and Bootstrap. I’d like to try and curb this
phenomenon before it takes off any more.

Problems with Slack


  • is closed source
  • has only one client (update: errata at the bottom of this article)
  • is a walled garden
  • requires users to have a different tab open for each project they want to be
    involved in
  • requires that Heroku hack to get open registration

The last one is a real stinker. Slack is not a tool built for open source
projects to use for communication with their userbase. It’s a tool built for
teams and it is ill-suited to this use-case. In fact, Slack has gone on record
as saying that it cannot support this sort of use-case: “it’s great that
people are putting Slack to good use” but unfortunately “these communities are
not something we have the capacity to support given the growth in our existing

What is IRC?

IRC, or Internet Relay Chat…

  • is a standardized and well-supported protocol
  • has hundreds of open source clients, servers, and bots
  • is a distributed design with several networks
  • allows several projects to co-exist on the same network
  • has no hacks for registration and is designed to be open

No, IRC is not dead

I often hear that IRC is dead. Even my dad pokes fun at me for using a 30 year
old protocol, but not after I pointed out that he still uses HTTP. Despite the
usual shtick from the valley, old is not necessarily a synonym for bad.

IRC has been around since forever. You may think that it’s not popular anymore,
but there are still tons of people using it. There are 87,762 users currently
(at time of writing) on Freenode. There are 10,293 people on OFTC.
22,384 people on Rizon. In other words, it’s still going strong, and I put a lot
more faith in something that’s been going full speed ahead since the 80s than in
a Silicon Valley fad startup.

Problems with IRC that Slack solves

There are several things Slack tries to solve about IRC. They are:

Code snippets: Slack has built-in support for them. On IRC you’re just asked
to use a pastebin like Gist.

File transfers: Slack does them. IRC also does them through XDCC, but this
can be difficult to get working.

Persistent sessions: Slack makes it so that you can see what you missed when
you return. With IRC, you don’t have this. If you want it, you can set up an IRC
bouncer like ZNC.

Integrations: with things like build bots. This was never actually a problem
with IRC. IRC has always been significantly better at this than Slack. There is
definitely an IRC client library for your favorite programming language, and
you can write your own client from scratch in a matter of minutes anyway.
There’s an IRC backend for Hubot, too.
GitHub has a built-in hook for announcing repository activity in an IRC channel.

Other projects are using IRC

Here’s a short, incomplete list of important FOSS projects using IRC:

  • Debian
  • Docker
  • Django
  • jQuery
  • Angular
  • ReactJS
  • NeoVim
  • Node.js
  • everyone else

The list goes on for a while. Just fill in another few hundred bullet points
with your imagination. Seriously, just join # on Freenode. It
probably exists.

IRC is better for your company, too

We use IRC at Linode, even for non-technical people.
It works great. If you want to reduce the barrier to entry for non-technicals,
set up something like shout instead. You can
also have a pretty no-brainer link to webchat on almost every network, like
. If you need file
hosting, you can deploy an instance of or something like it. You can also
host IRC servers on your own infrastructure, which avoids leaving sensitive
conversations on someone else’s servers.

Please use IRC

In short, I’d really appreciate it if we all quit using Slack like this. It’s
not appropriate for FOSS projects. I would much rather join your channel with
the client I already have running. That way, I’m more likely to stick around
after I get help with whatever issue I came to you for, and contribute back by
helping others as I idle in your channel until the end of time. On Slack, I
leave as soon as I’m done getting help because tabs in my browser are precious
real estate.


Addressing feedback on this article.

Slack IRC bridge: Slack provides an IRC bridge that lets you connect to
Slack with an IRC client. I’ve used it – it’s a bit of a pain in the ass to set
up, and once you have it, it’s not ideal. They did put some effort into it,
though, and it’s usable. I’m not suggesting that Slack as a product is worse
than IRC – I’m just saying that it’s not better than IRC for FOSS projects, and
probably not that much better for companies.

Clients: Slack has several clients that use the API. That being said, there
are fewer of them and for fewer platforms than IRC clients, and there are more
libraries around IRC than there are for Slack. Also, the bigger issue is that I
already have an IRC client, which I use for the hundreds of FOSS projects that
use IRC, and I don’t want to add a Slack client for one or two projects.

Gitter: Gitter is bad for many of the same reasons Slack is. Please don’t
use it over IRC.

ircv3: Check it out:

irccloud: Is really cool and solves all of the problems.

Original URL:

Original article

Near-Unlimited Cloud Storage Service Is Shutting Down, the cloud storage service that offered near-unlimited space and huge bonuses for referrals, announced today they’re shutting down on May 1st, 2016—leaving more than a few people with dozens or hundreds of gigs of data to migrate.

Read more…

Original URL:

Original article

How To Build a TimesMachine

necro81 writes: The NY Times has an archive, the TimesMachine, that allows users to find any article from any issue from 1851 to the present day. Most of it is shown in the original typeset context of where an article appeared on a given page — like sifting through a microfiche archive. But when original newspaper scans are 100-MB TIFF files, how can this information be conveyed in an efficient manner to the end user? These are other computational challenges are described in this blog post on how the TimesMachine was realized.

Share on Google+

Read more of this story at Slashdot.

Original URL:

Original article

DDoS attacks are now more sophisticated

DDoS attack start

Kaspersky Lab has released its report into DDoS attacks for the fourth quarter of 2015, and it claims that the global reach of attacks shrunk, but the sophistication of those attacks grew.

According to the report, in the fourth quarter of 2015, resources in a total of 69 countries were attacked. In the previous quarter, that number stood at 79. Similar to the previous quarter, in the last three months of 2015 the majority of attacks (94.9 percent) took place in just ten countries, with the US, China and South Korea being the most affected of the bunch.

A marathon DDoS attack was also noticed in Q4, one which lasted 15.5 days, or 371 hours. Linux bots are also on the rise, from 45.6 percent to 54.8 percent.

“We can see that the complexity and the power of DDoS attacks have not diminished with time, even if the number of attacked resources has fallen. Unfortunately, DDoS remains a convenient and affordable tool for online crime because there are still software vulnerabilities that attackers can use to penetrate servers”, said Evgeny Vigovsky, head of Kaspersky DDoS Protection at Kaspersky Lab. “There are also users who fail to protect their devices, increasing the chances of those devices being infected by bots. For our part, we are committed to providing businesses with information about the DDoS threat and promoting the fight against it, because DDoS is a threat that can and should be combated”.

The full Kaspersky Lab report can be found on this link.

Published under license from, a Net Communities Ltd Publication. All rights reserved.

Photo Credit: Duc Dao / Shutterstock

Original URL:

Original article

As Primary Season Opens, OpenText Releases Election News Tracking Tool

Vote buttons After months of debates, social media chatter, outrage and craziness, the presidential primary season finally opens today with the Iowa caucuses. In response to that milestone, OpenText announced it was releasing a new tool to help voters track news around the elections and parse that by candidate and issues. The tool is called Election Tracker 16 and it’s designed to showcase some of… Read More

Original URL:

Original article

Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.

Up ↑

%d bloggers like this: