I thought the talk was very informative and gave some great ideas for use of APIs out there. Most of the ones discussed seem like they may be a good fit for the application that my company built!
Avoid relying on conference wifi at all where possible. Annotated screenshots in slides can be a handy backup option. That said, the live demos were fairly impressive.
ZF2 structure / logistics are way too pervasive in the survey of example code; consider switching to a microframework or doing away with framework usage entirely for the sake of keeping examples simple and focused on API usage. Live coding seems to interfere with pacing; consider just pre-coding everything and including it in the survey.
Overall content of the presentation was good; the Gitgram example was a nice way to tie together several disparate APIs. I was personally hoping to see more APIs, but from what I gather, the intent of the presentation was more to encourage general consideration of APIs for outsourcing some tasks and integration of multiple APIs into a single application, and I'd say it accomplished that objective.
I thought the talk could be improved by focussing more on an architectural overview. It focussed heavily on the example project which leveraged a small handful of API's. Several more tools and API's were mentioned rapid-fire at the end of the talk. I would have appreciated hearing more of a broad perspective on the available tools.
Good talk but lower-level than I was anticipating. I was hoping for more exposure to the API landscape, i.e. what's available out there to tap into instead of building it in-house, and perhaps some tools/strategies to help integrating these APIs together.
This was a good primer on the ubiquity and power of APIs, with a nice dive into a couple specific examples. I could not type quickly enough to follow along with the tutorial, so it was nice to have the checkpoint tags to catch up
Question for those with feedback on the sample app - while (I thought) a novel approach, do you feel it would be better to explore some of these APIs on a individual basis?
A simple login example (not one tied to an overall application), a standalone use of a media conversion API, etc? Would that be a good way to remove the some of the heaviness?
Perhaps also make it easier to follow along / be hands on?
Learned about some useful APIs and a decent overview of implementing APIs. I would have gotten more out of it if framework-agnostic code was used, and if the pace was a bit slower.
I agree that independent examples of API applications may be a better fit, especially to help with following along. Giving an overview of the service and associated docs, an example service call or two, and maybe giving an exercise that enables the audience to use what they've learned and go a bit further in exploring the API might be an ideal presentation flow for each service. There's nothing to stop you from describing how the individual services might fit together into a particular whole application as more of an aside rather than the focus of the presentation.
It was cool to see that there really probably "Is An API For That". I haven't ever before tried to build an app using (almost) only other APIs that I didn't build but it was really cool to see the approach. I am much more interested in learning about a few of the APIs and technologies that were shown (like graph dbs) that I haven't been exposed to.
As far as the application, it was really ambitious. There is a bit of "going into the weeds" in ZF2 that is probably pretty tough to get around for people who are not familiar with ZF2. I'm not sure of a way to fix that other than considering Matthew's suggestion of using less framework (like a micro). I think building individual tiny apps that only each use a single API would possibly get through more APIs but would probably not be as interesting.
Very interesting how you can "outsource" certain application features by using APIs; I really like the variety of APIs used in the example, I think I found some gems I may use in the future.
As a 2.5h training I would have liked to have a more hand's on experience coding, or at least time at the end to write a small feature using one of the many APIs.
A lot of great materials provided and also useful pointers in building app with API. It opened my mind on how to use different APIs to accomplish my project. However, demonstration on writing code on each API seems to be a bit too tedious after first few APIs? If this one is a training, why not asking attendees to try to complete some codes. It would be more interesting and more interactive experience.
I felt the description didn't match the discussion. With an obvious knowledge of APIs he was able to develop a website in the time of the discussion by combining APIs to complete tasks. I was hoping the discussion would be more general and discuss the world of APIs. How to find them, are there good sources to find them. What makes a good API. How to save time find and learning to use different APIs, a list of APIs and redundant tasks.
I felt the class needs to be a day long class to allow for meaningful participation.
This would also give time for a survey of the world of APIs, how to find reputable ones as well as the pros and cons of using them. While you do can get things up and running fast with use of APIs, you also have to manage those dependencies during the life cycle of your product, this is worth discussing.
Comments
Comments are closed.
I thought the talk was very informative and gave some great ideas for use of APIs out there. Most of the ones discussed seem like they may be a good fit for the application that my company built!
Avoid relying on conference wifi at all where possible. Annotated screenshots in slides can be a handy backup option. That said, the live demos were fairly impressive.
ZF2 structure / logistics are way too pervasive in the survey of example code; consider switching to a microframework or doing away with framework usage entirely for the sake of keeping examples simple and focused on API usage. Live coding seems to interfere with pacing; consider just pre-coding everything and including it in the survey.
Overall content of the presentation was good; the Gitgram example was a nice way to tie together several disparate APIs. I was personally hoping to see more APIs, but from what I gather, the intent of the presentation was more to encourage general consideration of APIs for outsourcing some tasks and integration of multiple APIs into a single application, and I'd say it accomplished that objective.
I thought the talk could be improved by focussing more on an architectural overview. It focussed heavily on the example project which leveraged a small handful of API's. Several more tools and API's were mentioned rapid-fire at the end of the talk. I would have appreciated hearing more of a broad perspective on the available tools.
Good talk but lower-level than I was anticipating. I was hoping for more exposure to the API landscape, i.e. what's available out there to tap into instead of building it in-house, and perhaps some tools/strategies to help integrating these APIs together.
This was a good primer on the ubiquity and power of APIs, with a nice dive into a couple specific examples. I could not type quickly enough to follow along with the tutorial, so it was nice to have the checkpoint tags to catch up
Question for those with feedback on the sample app - while (I thought) a novel approach, do you feel it would be better to explore some of these APIs on a individual basis?
A simple login example (not one tied to an overall application), a standalone use of a media conversion API, etc? Would that be a good way to remove the some of the heaviness?
Perhaps also make it easier to follow along / be hands on?
Learned about some useful APIs and a decent overview of implementing APIs. I would have gotten more out of it if framework-agnostic code was used, and if the pace was a bit slower.
I agree that independent examples of API applications may be a better fit, especially to help with following along. Giving an overview of the service and associated docs, an example service call or two, and maybe giving an exercise that enables the audience to use what they've learned and go a bit further in exploring the API might be an ideal presentation flow for each service. There's nothing to stop you from describing how the individual services might fit together into a particular whole application as more of an aside rather than the focus of the presentation.
It was cool to see that there really probably "Is An API For That". I haven't ever before tried to build an app using (almost) only other APIs that I didn't build but it was really cool to see the approach. I am much more interested in learning about a few of the APIs and technologies that were shown (like graph dbs) that I haven't been exposed to.
As far as the application, it was really ambitious. There is a bit of "going into the weeds" in ZF2 that is probably pretty tough to get around for people who are not familiar with ZF2. I'm not sure of a way to fix that other than considering Matthew's suggestion of using less framework (like a micro). I think building individual tiny apps that only each use a single API would possibly get through more APIs but would probably not be as interesting.
Very interesting how you can "outsource" certain application features by using APIs; I really like the variety of APIs used in the example, I think I found some gems I may use in the future.
As a 2.5h training I would have liked to have a more hand's on experience coding, or at least time at the end to write a small feature using one of the many APIs.
A lot of great materials provided and also useful pointers in building app with API. It opened my mind on how to use different APIs to accomplish my project. However, demonstration on writing code on each API seems to be a bit too tedious after first few APIs? If this one is a training, why not asking attendees to try to complete some codes. It would be more interesting and more interactive experience.
I felt the description didn't match the discussion. With an obvious knowledge of APIs he was able to develop a website in the time of the discussion by combining APIs to complete tasks. I was hoping the discussion would be more general and discuss the world of APIs. How to find them, are there good sources to find them. What makes a good API. How to save time find and learning to use different APIs, a list of APIs and redundant tasks.
Description did not match the content.
I felt the class needs to be a day long class to allow for meaningful participation.
This would also give time for a survey of the world of APIs, how to find reputable ones as well as the pros and cons of using them. While you do can get things up and running fast with use of APIs, you also have to manage those dependencies during the life cycle of your product, this is worth discussing.