Atlassian provides a freely available to the public, command line interface (CLI) for at least some of the tools in their suite. The CLI downloads and documentation are located here. The scripts include a parameter for the password. The password is used to log into the server. No one wants to, nor should they ever, hard code the password in a script.
Here’s a technique to avoid having to hardcode the password when using one of the Altassian shell scripts:
This technique is not ideal…you have to type in the password each time you execute the script. Also, if you use the CLI for two or more Atlassian tools, you have to maintain a separate script for each. A next step would be to write a new script and pass it a parameter for the tool you want to access and the password.
unixODBC is a mess. I installed pyodbc last week. My configuration got wonky. I couldn’t use ODBC. I couldn’t connect to Greenplum from Tableau. I was caught in the tar pit and needed help. Apple no longer supports an ODBC manager application. I decided to try one of two ODBC manager applications that I could find. I tried ODBC Manager. Here’s the About screenshot:
My verdict on ODBC Manager: Don’t use it.
I don’t think it’s a supported application. I was trying to create user DSNs. I expected the odbc.ini and odbcinst.ini files to get written out to directory /Users/user/Library/ODBC. Instead, the files (at least odbcinst.ini) were written out to /Library/ODBC.
The app has a bug. You can’t delete driver information from within the app. If you trash the app, the artifact of the odbcinst.ini file will remain. To delete the file, first locate it using this command:
sudo find / -name odbc*.ini 2>/dev/null
Remove the file. Then go back into the app. The driver information is gone.
If you don’t have it installed, don’t install it. If you do have it installed, make sure to remove the ODBC configuration info and then trash the app. (I don’t think the app saves data in directories /Users/user/Library/Containers, '/Users/user/Library/Application Support', or /Users/user/Library/Preferences/, but I can’t 100% vouch for this.) I don’t have a recommendation for a GUI for unixODBC management tasks on Mac OS X. The unixODBC project has as an aim a GUI for KDE and GNOME. Let’s hope that Apple re-releases one. In the meantime, use the command line. And, bonne chance!
The Mary Meeker Internet Trends Report 2016 is very good. I think her summaries of the macroeconomic and growth trends are in alignment with the other sober and rational thinkers. She moves quick through the content.
This post shows how to include a job number with Perforce changelists submitted from the Bash prompt. Here’s an example of the error:
[user-name@server-name ~/scripts]$ p4 submit -d "ABC-1234 Testing Scala connection to Oracle"
Submitting change 2011453.
Locking 1 files ...
Submit validation failed -- fix problems then use 'p4 submit -c 2011453'.
'bugattached' validation failed: Submissions to this branch must have a bug attached
The strings ABC-1234, changelist number 2011453, and the description, are fill values for use in the post to illustrate the problem and the solution.
If you’re receiving this error at the command line and end up going back to the Perforce visual client, read on. There is a way to submit at the command line. The terms bug number, and job, are equivalent to the JIRA ticket number that I use here.
Including JIRA ticket
The above error is obtained when a validation rule in in place that a bug has to be associated with the changelist. The fix is a three-command process:
Note: System responses that are displayed after each of the commands have been removed.
It’s a three-step process. It works. Reading the Perforce documentation, it looks like there is a second way to submit at the command line, and using just one command. This second way uses the Jobs parameter within the Perforce Form Field: usage. I couldn’t find a working example. Spending time on it myself, I couldn’t figure it out. If you are aware of how to use the form field, please write in with a comment!
The R vs. Python language war is dead. This is an observation from Strata + Hadoop World San Jose 2016. There were no discussion among participants about the merits of one over the other. Nor was there any content about which is better in any of the sessions that I attended. In a show of acceptance of using either language for Data Science, a full-day tutorial was held for each of the two languages.
What has instead emerged is acceptance that Python is the more general purpose of the two while now also being well suited for Data Science. And that R is the statistical-domain specific of the two while also being well suited for Data Science.
What’s emerged is that the technical challenges underlying integration of these languages into Big Data are essentially the same. A key post by software engineer Wes McKinney discusses the the commonality. It’s an important post. Read it here.
The language war is dead. A takeaway is that it’s not one or the other but both. Data Scientists will need to know both. Being more fluent in Python is better. Having enough facility in R to get data into and out of the R ecosystem, being able to use and interpret results from statistical tests, and being able to use the visualization libraries, is probably enough.