YouTrack to Slack Bot

Well we’ve finally been able to open source our YouTrack to Slack bot.  This is pretty exciting to share.   Here at Cinchcast we love to use YouTrack and Slack.  However YouTrack only currently has XMPP support.  We built a bot that will take XMPP messages and forward them to a Slack Incoming Webhook.

This is a simple NodeJS application that uses XMPP and HTTP to make the conversation work.  It’s pretty configurable as far as diving messages amongst different Slack channels.  You can check it out here, fork it, contribute, open issues, enjoy


Load Testing Using FreeSWITCH

Here at Cinchcast being able to load test telephony applications is very useful.  It can help with observing different scenario, such as code, bottlenecks, and/or CPU load conditions.

We have a Lua script called “SummonDialer” that we utilize to accomplish this.   But utilizing the FreeSWITCH web server capabilities we can run another shell script to loop through this n times.

We also have IVRs that we have to pass through sometimes, so this also allows us to wait a specified amount of time and pass DTMF.

You can head over to the cinchcast/freeswitch-load-tester Github repository and read more about it.  Feel free to fork and contribute a pull request.


Swagger and swagger-codegen in C#

Swagger-codegen is script package written in Scala that does code generation for a “Swagger Enabled” web service. What is Swagger?

“Swagger is a specification and complete framework implementation for describing, producing, consuming, and visualizing RESTful web services.”

Here at Cinchcast we are using Dropwizard to create RESTful web services. Since Dropwizard uses Jersey, a JAX-RS implementation, we can easily use Swagger

Swagger essentially takes a web service and describes it in a simple JSON format. From this, swagger-codegen can parse it and automatically generate client libraries.

At Cinchcast we code much of our Web-based applications in C# which requires engineers to write boilerplate code to wire up HTTP calls. This can become an issue when services change; communicating those changes presents another issue.

Since no C# scripts were written, we took on the task of writing them and submitted a pull request. Please feel free to take a look at the code and provide any feedback.


NodeJS v0.8.16 on CentOS

CentOS is the Linux distro of choice with many developers because of its community support and stability. It’s based on the Red Hat kernel and is one of the most popular distros for web servers.

One downside of this, is less support for working with bleeding edge packages. CentOS maintains its stability by not releasing rpm packages before running them through a gambit of testing. Updates are less frequent in order to prevent breaking dependencies. This lack of dependency control makes installing bleeding edge software more complex.

In contrast, Ubuntu or Fedora you would be able to do an apt-get or yum and package management would know what latest dependencies are needed. Thus there is no need to do anything special to work with bleeding edge installs.

Cinchcast depends on Node.js and its continual updates. To make working with the bleeding edge of Node on Centos easier, I’ve written a script that will build the main dependency for Python 2.7 with bzip2 support and then compile the nodejs code from source.

# retrieve
curl > centos5.8-upgrade-nodejs0.8.16.tar.gz
# extract
tar -xvf centos5.8-upgrade-nodejs0.8.16.tar.gz --strip 1
# prepare
chmod 744
# execute
sudo ./
# cleanup
sudo rm -r bzip2-1.0.6* centos5.8-upgrade-nodejs0.8.16* Python-2.7*

Once you are done, run this command:

node --version

This should return the appropriate nodejs version. In this case the version is v0.8.16.

You can view the script or fork it here if you are interested:


jwPlayer on iOS

Here are Cinchcast we use jwPlayer for handling syndication of our audio content. Because of certain functionality of iOS, the jwPlayer library overrides it’s own functionality in favor of allow iOS to handle the video tag in HTML.

As we don’t use video on our platform and have our own custom implementation using slides with PopcornJS, this causes a lot of issues for us.

Here is a snippet from jwPlayer’s website as to why they do this.

iOS specific limitations

In order to ensure the best possible user experience on iOS devices, Apple has placed some stringent controls on how video can be viewed and controlled on these devices. The JW Player works around these as best as possible, but the following limitations still persist:

  • Video cannot be viewed in context on the iPhone – video is always viewed in fullscreen in the native playback application.
  • Video cannot be started programmatically – users must click on the screen to trigger playback. Additionally, no visual elements sitting over the video tag will receive click events while the video is visible (playing or paused).
  • Volume can only be controlled via the built-in controlbar and the device controls.

To get around some of these issues, the JW Player uses the native iOS controls, but continues to send out all API events. Note that some API commands will not function as expected.

There is a very easy to work around this. Essentially you override the function in the library prior to jwPlayer being initialized that tells the player that you are never on a specific mobile device.

jwplayer.utils.isMobile = function () { return false; };

Once the player is called, it will show the jwPlayer HTML5 player instead of the native iOS one.