Great Java - Caffeinated Babblings!

  • Home
  • Coffee Brewing HOW-TO
  • General
  • Web
  • Coffee
  • Java
  • Social Media
  • Coding
Caffeinated Babblings!

coding

Coding to Kaltura API using “testme” Console

January 19, 2016 by The Great Java

I’m probably too easily impressed anytime a vendor shows me a web “playground” to experiment with their API, especially if it will generate code snippets for specific languages. IBM has a pretty neat tool for IBM Connections, but it requires too much setup/footprint in my opinion. Kaltura has something similar, but has the advantage of needing just a client library. I needed to get a list of owners and managers for channels in the KMS and it seemed like for a few calls, the test console could give me the basic code.

I started with JavaScript and ran into a lot of trouble, which I chalked up to my proxy for the request. I figured server-side Java would be a better choice since I wouldn’t have to deal with the cross-site scripting and it’s a language I know well. With the Kaltura API, you start by creating a “session” (also called a “ks” for Kaltura session). You can do this with your secret admin code, but it’s far better to do it with a user that has the privileges you need. I generated some of the basic code and pasted it into a runnable class.

Kaltura Generated Code

KalturaConfiguration config = new KalturaConfiguration();
config.setPartnerId(partnerId);
config.setEndpoint("https://www.kaltura.com/");
KalturaClient client = new KalturaClient(config);
String loginId = "userid";
String password = "password";
int partnerId = 999999;
int expiry = null;
String privileges = null;
Object result = client.getUserService().loginbyloginid(loginId, password, partnerId, expiry, privileges);

Immediately, I noticed some interesting things like assigning primitives to null and declaring variables after they are used, which are easily fixed, but the issues don’t end there. The return types are not usable (all objects) and the API calls don’t match the API you downloaded from the test application. Other code examples were worse-variables were declared when all that was needed was a simple assignment to something already created.

In hindsight, I expect it wasn’t my proxy or JavaScript skills, but similar code generation issues and API mismatches that were my downfall with JavaScript. My advice is to try the console to know what classes you’ll need and get a “hint” of what data is passed around-assume the code you get is just plain wrong. I posted my experience in the forums and the response was that Java isn’t as well supported as PHP and it’s just a guide to the type of code you might write. They have a developer site with code examples, but nothing in Java yet.

In case you were hoping to find some working sample code, I’ve attached code to create a session, get a list of categories, and print out all the users with manager access in case you’d find a complete code example useful.

Download ListChannelOwners Java Class

Posted in: Coding, Java, Web Tagged: coding, Java, kaltura

Diagnosing problems with First Robotics Simulator (FRCSim)

April 9, 2015 by Mark

WPI in conjunction with the Open Source Robotics Foundation has developed a 3-D simulation tool for FRC teams coding their robots in C++ or Java with WPILib. It’s pretty much limited to the sample robots you get with the development package right now but it’s great for students to try out the code or use the command framework to build some new commands. This exposure to the API doesn’t require a robot – which in the first few weeks of the project is a great thing. [more details]

The underlying tool for the FRCSim, Gazebo, isn’t very friendly about telling you what the problem might be before it dies an ugly death. Most likely the problem is you’re seeing errors about the “Gazebo Transport” in Eclipse since it’s unable to connect to the dead Gazebo server. I’ve documented some steps to try and determine the cause of your problem.

1) Make sure you’re following the latest steps for running the tool and have a proper updated Ubuntu installation. You need to be on the 64-bit version of the OS. To verify this try typing the following on the command:

> uname output

You should see X86_64 in the output. If you don’t your machine isn’t compatible or you installed the 32bit OS version.

2) Try running the following command to launch the Gazebo server directly and look for any human readable errors in the log:
> frcsim -u –verbose /usr/share/frcsim/worlds/GearsBotDemo.world

You can look at the log files in ~/.gazebo for any useful error information. It will be cryptic but maybe you’ll find something useful. I wouldn’t spend a lot of time here but maybe you’ll see some obvious failure.

3) Determine if your card supports direct rendering. Try the following command. If you see output of “direct rendering: Yes” that’s good.
> glxinfo | grep “direct rendering”

If you don’t see the right output see step below.

4) If you’re still stuck your video card may not be supported. If you’re using an integrated controller you’ll likely need to try an ATI or nVidia dedicated card. I tried 2 linux laptops and a desktop all with integrated controllers from a variety of vendors (with correct support for direct rendering). Only after updating the desktop with a super cheap $30 nVideo card was I able to get the simulator to run – and runs pretty well from limited testing.

If you’re stuck hopefully some of the stuff above helps out. Thanks to Alex Henning for the tips!

Posted in: Coding, General Tagged: coding, robotics

Copyright © 2025 Great Java - Caffeinated Babblings!.

Taste WordPress Theme by ThemeTaste