The Philly JUG had another successful meetup this week. This week’s topic… Pepper The Robot!
One of the biggest things I learned was to think of a humanoid robot as a device for engaging people within a specifically programmed domain – like the way you engage with your phone. It’s not a sci-fi android, and it’s not an AI that can have arbitrary conversation… yet! If you walked up to a robot in a department store and said “I’m looking for a blue shirt that matches the pants I’m wearing”, you would get a robotic blank stare. Instead the robot might initially grab your attention by waving, and as you approach it, it might start a conversation with “I’m here to help you! Do you want to charge your phone? Or can I call someone from another department for you?” This provides a more engaging experience for the human because you can interact with a computer in a human-like way.
Speaking with the presenter Nicolas, he said that humanoid robots are still in the early stages of development. They are currently like the Atari 2600 to The Terminator’s PS4. But if you find yourself stuck in 1982 you don’t have to sit around waiting for the PS4, you can have plenty of fun with what you have, and even work to advance the state of the art!
Do you think you would want to program humanoid robots?
The Philly Java User’s Group (@ThePhillyJUG ) recently hosted a talk about the JCP and about how to get involved with the future of Java.
Slides are here but I thought was the key takeaway was the list of fairly easy ways to get involved:
- Share ideas and feedback, comment on list and public issue trackers
- Read early version of specifications and Javadocs
- Try writing sample applications using early builds of reference implementation
- Write or speak about the technology and encourage others to participate. Translate into your native language
- Evalgelize the JSR via social media, blogging, or lighting talks.
- Help with documentation.
Get involved at http://adoptajsr.org!
I have been thinking about Scrum and Agile lately, and thought it would be fun to look into alternatives to story points. I’d heard that if you are consistent with your story sizes, that they average out and you can estimate your sprints by number of stories instead of by number of points.
Here’s the story on estimating without estimating:
Conclusion and Recommendation
Story points and estimating can be abused, but I don’t think that’s necessarily a reason to abandon them out of hand (as anything can be abused). I would recommend focusing on teaching teams to create small and well-defined stories, which helps whether you use point estimates or not. At a certain level of Agile maturity, you can evaluate if you think this could be a good idea for the team.
What do you think? Do you estimate by story points, by number of stories, or something else? Or not at all?
PS in my research I found this neat chart for patterns for splitting stories!