[JdeRobot] Presents for Christmass: my contributions to simplify developers life.

[Victor Arribas]

Ho Ho Ho, Happy Christmas to all

I'm feeling Santa Claus spirit, so I will here to give your presents for
Christmas.

This year there is a lot of new features that will simplify developer life.
let's start ;)


I present you... *EasyIceConfig*

*Are you asking God why you need to run components from a specific
directory or at least copy ice config files to current directory just to
execute?*

EasyIce comes to rescue you!
It brings possibility to use a ice config file from another well-known path
without put whole path.

It hold more features. Would You Like to Know More?

   - https://jderobot.org/Varribas-tfm/contribution/libeasyiceconfig
   -
   https://github.com/jderobot-varribas/libeasyiceconfig/releases/tag/0.9.2


I present you... *EasyProxy*

*Are you jaded to write again and again same lines just to raise up an
Ice's Proxy?*
*create a vanilla proxy, do an explicit cast, and evolve all in a try
catch..., and repeat it for each adapter..."*

With EasyProxy create a Proxy is no more painful. No more try catch, no
more complex initialization.
See the example here
<https://github.com/jderobot-varribas/JdeRobot/commit/a68ce921ccaf1f0fe5a4905d67b89cf63d632491?diff=split>
!

Related links:

   - https://github.com/RoboticsURJC/JdeRobot/pull/269
   -
   https://github.com/jderobot-varribas/libeasyiceconfig/releases/tag/0.9.3.1


I present you... *Single Adapter communication scheme*

*Are you tired to do exactly same again and again for each interface?*


* - put almost same Endpoint entry for each interface- define a lot of
naming convections that every user must to known.- create an adapter for
each interface- be obey to use a lot of port and be stuck due one was a
typo- cry every time that you want to power up several instances of same
component*

Today is your lucky day. All this overload is not required!
My present for you is "Single Object Adapter approach", it is highly
recommended by Ice; so if you want not obey me, just obey they ;)

Related links:

   - https://github.com/RoboticsURJC/JdeRobot/issues/199


I present you... *New Gazebo's plugin develop scheme*

*Are you jaded to...*

   - *edit every model file when you want to add "intelligence"?*
   - *do a plugin for each sensor?*
   - *be stuck because code can not be reused and there is a hard
   dependency between model and code?*

Here you are my new not-patented develop scheme!

   1. Do a single model plugin that just gather all
      - Gather links to allow part by part control.
      - Gather every sensor through *SensorManager* and just connect to
      *Update* event
   2. Evolve vanilla model with intelligence layer
      - Reuse already provided models
      - Create as many variations as you wish reusing same vanilla model

Do you think that I kidding you?, see a functional example of this new
schema

<?xml version="1.0" ?>
<sdf version="1.4">
  <model name="flyingKinect">
    <plugin filename="libgazebo_kinectplugin.so" name="kinectplugin"/>
    <static>true</static>
    <include>
        <uri>model://kinect</uri>
    </include>
  </model>
</sdf>

What it implies?

   - No more manage nor clone model files (100-500 lines)
   - No more almost empty SensorPlugin
   - No more dedicated threads
   - Nno more complex solutions to allow intercommunication.

Would you like to know more about architecture? See
[[Varribas-tfm/review_quadrotor_plugin#Quadrotor_plugin_2.0|Quadrotor_plugin_2.0]]

Would you like to see a basic example? See
https://github.com/RoboticsURJC/JdeRobot/pull/270


I present you... *Build Aliases/Groups*

*Are you jaded to lost hours compiling entire framework? Have you ever
tried component based build and eventually get jaded to write a infinite
line of -Dbuild_whatever?*

I present you Build Aliases (or just build groups). This feature manages
comes to rescue you, so now you can overcome it with a *single* -Dbuild_X.

But wait! this present is forearmed.
*What happens if I want to add my own groups. Is there any risk of mess git
if I do not be careful?*
No!, you can add all you private, dirty and incomplete job inside
*buildpresets_userdefined.cmake*, this file is blacklisted and will not be
pushed into repo.

Related links:

   - https://github.com/RoboticsURJC/JdeRobot/issues/250
   - https://github.com/RoboticsURJC/JdeRobot/pull/264


I present you... *Out-of-Source Build*

*What did you say!? out-of-source build as a new feature? I couldn't use it
before? Why!?*

Yes, you are right. This was a missed feature and some one must revive it.

Related links:

   - https://github.com/RoboticsURJC/JdeRobot/issues/236
   - https://github.com/RoboticsURJC/JdeRobot/pull/237
   - And even more effort scattered between commits


I present you... *Incremental Releases*

*Why when someone tell me that there is a new version at repository I must
to uninstall current jderobot package and install it again? Why apt-get
update do not notify me about this change?*

Because release system do no exists.
So.., I present you Incremental Releases, the self-managed system to
overcome it.

   1. Creates a two-based versioning workflow:
      - Remove ugly '-rc1' from mainstream. Framework versioning is cleaner
      and simpler.
      - Do not need to make dirty git. So framework versioning is untouched.
   2. Remove maintainer to do a lot of extra effort.
      1. remember what was last version at repository
      2. touch version number and revert it again because it was not
      planned to roll up
   3. Do not lie user with a new package with exactly same version number.

Related links:

   - https://github.com/RoboticsURJC/JdeRobot/pull/275
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://gsyc.escet.urjc.es/pipermail/jde-developers/attachments/20151225/3f954d86/attachment.htm