By forever, I mean it took me almost an hour. That says something about our access to information and my own expectations, but that's another blog post entirely.
The trouble happened because of the nature of my question - which the StackOverflow post does a good job of explaining - I'm trying to call one integration from another. This leads to a semantic overlap of the parts question I'm trying to ask.
I like to envision this as the question collapsing on itself, inside of Google, but I probably don't really understand that as well as I think I do, and I did just watch Tron recently.
Plus many variations of 'call a slash command from web hook on Slack' leads me to Slack's own documentation where they don't answer this question (as of this writing 3/1/2016).
In the end the answer is obvious - you can't call one integration from another. This prevents a lot of attacks or spamming that could probably happen if you had a wide open gateway to push data through Slack.
How did I find it in the end? Brute force querying google until I found a result that didn't look like all the other slash command/web hook posts and documentation that are out there.
Final Google query - 'pass giphy to slack api' which removes the confusion by specifically naming the thing I'm trying to do - 'giphy' - instead of just asking more generally about slash commands.
It was the 4th result.
I have to teach my kids all this some day. Maybe they will just grow up knowing how to do it.
ID-GEM is a new product we've just rolled out Amadeus. It's joint effort between a few groups (sales, estimation, software, marketing) within the company. It encapsulates and expands on our business development and requirements gathering process that we've been refining over the years. I also wrote a blog post about it for work here.
The core of the product is that software projects almost always fall into one of five categories, and if you spend the time up front to think about which category you're in and how you want to achieve your goals, you can have a great framework for making crucial decisions down the road as your product or project moves through its life cycle. Here are the categories:
Capturing Market Share
Revenue (Increase/Create) B2C
Revenue (Increase/Create) B2B
Reduce Costs or Increase Efficiency
Improve Community or Well-Being of Users
We looked back over 20 years of consulting to determine these categories, as well as what we felt were the most telling, challenging, and crucial questions for projects to wrestle with at the beginning. This enables you to have the right answers in place when things get challenging down the road. The questions can be quite different depending on which of the categories you fall into.
If you are considering a software venture of some kind, you should take a look. It's free and easy to use.
I have heard from some parties that the cloud technology offerings that are gaining traction now (Google Cloud, Microsoft Azure, Amazon Web Services) are going to bring about the "death of IT".
First of all this is a big overstatement. Next, I also think these technologies are actually going to be net job creators, and not just for developers.
This is true because more small companies can afford to build-out infrastructure and therefore we will have more technology startups, which will create more jobs.
I also think that existing IT jobs likely aren't going anywhere either. These environments (Azure, Google Cloud, AWS) are complicated and it takes a good IT professional to learn them, set them up correctly, and manage them. There is a lot to learn here, so A) people need to go learn it and B) smart people need to be in charge of managing it in the long run.
And, interestingly where there were basically two flavors of IT in the past (Windows and Linux) now you have 3 - Microsoft, Amazon, and Google. Even though Amazon and Google are based largely on Linux, the two service offerings are not the same thing. They have different services, different UI, different structures. To be an expert in one is not to be an expert in the other.
To me this is nothing but good news from a competitive standpoint (3 options vs. 2 options) but also from a job creation and economic perspective.
The other good news? Since these platforms actually run VMs in a lot of cases, your existing IT expertise will still be applicable as well.
Virtualization probably has had a negative effect on jobs thus far, but the next stage will almost certainly create jobs, and opportunity, for those willing to learn and pick up new skills.
In software we leverage some construction terms when we talk about software projects.
Greenfield - a new software project that is not built on a previous project. AKA - blue sky, carte blanche.
Brownfield - a project that is adding onto an existing product. AKA - enhancements, feature work, new version development.
I am going to add to this the idea of Bluefield. This is a project that is a rebuild, from the ground up, of an existing application.
This is very particular to software and I don't know if it has a counterpart in traditional construction.
This project is neither Greenfield (not brand new because it must fulfill requirements of the original system) nor Brownfield (not built on an existing product).
Why are the fields blue?
Let's say that Bluefield projects are akin to the blue sky of a new project (you often have a clean slate on technology), but you can have some sadness about the passing of a tried-and-true system that served you well for some period of time.
Blue is also associated with harmony, faithfulness, and imagination all traits that should be valued in our rebuild project -
Harmony in important features.
Faithfulness to the business intent.
Imagination required to overcome project challenges.
I recently rebuilt our employee recognition tool using AngularJS.
The old tool had been built as an add-on to our case management tool, which we are migrating away from.
Since Angular is our preferred web direction, I believed it beneficial for me to dabble a bit and rebuild it using a modern, strategic technology.
The process was challenging for me mostly because I was not much of a JavaScript developer back when I did a lot of development. So, to do almost all my development using JavaScript required a fair amount of brute-force-through-googling just to get me past the basics.
Once I was able to do that, it was relatively simple to get done what I needed. My app was about 6 pages with 2 input forms, 3 grids, and a port of an old jquery-centric billboard form with some basic fade-in/fade-out animation.
This was no enterprise system mind you, but it had enough moving parts for me to learn the basics and prove to myself how hard it was going to be for others to learn.
For our existing JavaScript stars this will be an easy technology jump, but for others it will involve training on both JavaScript and AngularJS best practices.
The Amadeus Innovation Team has already developed a lot of our AngularJS best practices so that portion of the transition process is covered. There's a fair amount to think about in terms of project structure and approach, but I have left that to the more expert development minds.
Jonathan Fries on .