javascript drag and drop: problems with dragleave

i don't have much experience with javascript and jquery, but recently i started playing with MeteorJS (and i love it - but about this in a different post).

i'm dragging something onto a div and want an effect of openning jaws. yes, thats right - jaws :) i settled with jquiery-ui toggle, but then decided that addClass/removeClass would be good enough.

and here started the trouble with drag events - as for a single drag over my (large) area i got too many enter/over/leave/exit events, that were causing the "jaws" to toggle non-stop instead of opening on dragenter and closing on dragexit (or dragend - but i never got this event fired; or dragstop - which should be jquiry's killer drag finish event - alas not fired either for some reason).

it took me some time to realize that the nested div and other elements withing the target div were causing this constant enter/leave madness, which was breaking my flow.

so what to do? in an enviroment clean as this one everything is nice and clean, so how can i stop the sub elements from breaking my drag flow? it seems impossible...

so my idea to solve it is based on this:

my events are handled for the div id:

'dragenter #sidebar': function(e, t) {

but what if i'd be able to differentiate between event targets and fire the closing 'close jaw' event when a really non related target sends one of the drag events? but how? here's how:

as you can see, for example on mozilla's site, the drag events have a currentTarget property, but also a relatedTarget property - which it turns out we can use to detect the origin of the previous event - that is, for example - for a dragLeave event: the element that drag operation has left.

so now, our event catcher/handler becomes like this:

  'dragleave .drag-leave': function(e, t) {
    e.stopPropagation();
    e.preventDefault();

aaaaand - we need to add to all subelements of our div the subclass .drag-leave, so that we can check with a simple

if (e.relatedTarget && e.relatedTarget.className.search("drag-leave") == -1) {
      console.log(e.relatedTarget);
      $('#animTarget').removeClass("myClass", 1000, "easeOutSine");
    }

if we should close the jaw and finalize our effect.

so

is this a silly approach? please let me know, for now it works for me

create a slim and lean docker image for your go/golang application

all well and dandy - we have our app, it is running inside a docker image - yet there is still something we could do better.

hit 'docker images' and take a look at the output

REPOSITORY   TAG        IMAGE ID       CREATED         VIRTUAL SIZE
deligo       latest     11e4c299c1e0   39 minutes ago  755.8 MB

anything bothering you? this 755MB for the image kindda bothered ME.
so much space for an executable, which is less then 1% of this.
lets see how we can improve this

of course, this problem is not something new and many have looked and found solution that satisfies their case. in most cases the solution was using an image of an extremely slim linux distribution - alpine linux

it comes with only about 5 megabytes and through its packaging system - apk - allows you to only install packages you need

now, in my original Dockerfile i was actually building the executable inside the container, but we don't really need this right now, do we? in many cases it would probably make sense - thus the image will be able to grab latest code and build and run the latest executable, but on the other hand you may not wish to have your source code out, even in a secure environment like a docker image.

so, we will just ADD our executable to docker and it will run it away.
here is one of the benefits of compiled go executables - the practically have no dependencies (alright, this is only in my silly case, but i think this is also pointed out by golang dev community as well).

so lets do this.

if we sticked with building our app inside the image we'd have put in the Dockerfile something like

RUN apk add --update go && \
    rm /var/cache/apk/*

but we won't, so we won't: we're are only adding our executable with an ADD command

ADD deligo /go/bin/

and setting the entrypoint

ENTRYPOINT /go/bin/deligo

build and run away!
by the way - here are two useful switches to docker build cmd:

--no-cache=true
--rm

no-cache is especially useful when your executable has changed. i had some problems until realized that docker uses a cache for each step when building the image - which is good, but this cache doesn't seem too smart if it cannot realize a file has changed. so now i use this cmd arg for every build
rm of course removes not needed working data created during the build, and i believe essentially not needed

so, we built the image, we start it with docker run (don't forget to supply -p 8080:8088 or whatever, if your app has IO over ports), and then...
well in my case it was something like

deligo not found

but how it may not be found when i see it in the folder on the image and i can even sh to the image and run the file and..not found!? oh

so while we copied our executable to the image, there still seem to be some dependencies to syslibs which our slim alpine linux doesn't include. we can probably research which and add them, but this will inevitably make our image bigger. may be lets just sigh heavily and do it - include the whole go build chain etc - but turns out this might not even work, because at least for me alpine's

apk --update add go

only added go v1.4, even though i see go v 1.5.1 at their packages site. i found some workarounds for this, but none worked for me.
yet i found an excellent tip on codeship.com 's site, on how to build our go app with all libs statically linked into the executable:

CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o deligo .

further in the article there were some discussions on SSL which i didn't bother to read, instead hurrying to build my app with the tip above and rebuild the docker image, and start it and...yes, it runs!

actually, no - it doesn't :( when my app tries to read/write through the ports, some mysterious message was dumped:

x509: failed to load system roots and no roots provided

what?

nicely, the first search result was this - https://github.com/docker/docker/issues/3825, and mentioning SSL, i remembered the text on codeship's site and so quickly switched to it, to find the final solution: you need to provide certificates to your app, in order to satisfy go’s x509 library

ADD ca-certificates.crt /etc/ssl/certs/ca-certificates.crt

phew
(by the way - is it safe giving out certificates like that, any ideas?)

with this done - the rest is safe sails, and favorable winds...

yes, btw - our docker image got from 750MB to only 15 (15!!!!!) MB!!!
not too bad, eh?

docker image, ports and remote connections

soooo, very quickly i stumbled on a problem with my app i was deploying with docker.
the app opens a port and docker allows to redirect ports on the image to different ports on the host, so i was running

docker run -t -i -p 8090:8080 deligo

but i couldn't connect to 8090.
or rather netcat/nc was showing it as busy, but it wouldn't open in a browser.
so what was happening?

luckily the very first search result on duckduckgo provided the insight (stackoverflow.com):

Docker container published ports not accessible

i quickly checked and indeed in my go app i had started my http listener for 127.0.0.1 which as it turns out does not allow remote connections!
quickly changed to 0.0.0.0 and the whole chain works fine now, yeey!
 

create docker image for your go application

just wanted to give a try to docker so i gave a try J

somehow i thought that docker is a really magical tool and you just point it to your executable and it gathers all dependencies and pops the image wrapped in a pink pandelka.
well - not so J

but it really is not too difficult to make a docker image - there are just a few not too difficult steps.

my first impulse of course was to snap an ubuntu image and set up everything there manually:

docker run ubuntu:14.04 -t -i /bin/bash

and then install go, setup paths blah blah

luckily i noticed somewhere that there is a handy golang docker image already so i grabbed it and tenderly started it

docker run -t -i golang  /bin/bash

not many thing around, but enough to get us started

now, you can of course can still setup the golang image to your needs manually, but it is so much clever to have docker do this automatically for you!
for this purpose we will use a Dockerfile and build our image from it.
this will actually enable us to start as many instances of our app simultaneously in dedicated docker images with a wave of the hand.

so what do we need to put in this file?
first we need to tell docker which base image we will use; in our case this is the golang image:

FROM golang

i will deploy the app i think i mentioned in another article, which is hosted at https://github.com/esdee-git/deligo.
but for this example i won't grab it from github, but from my local drive; and i want docker to copy everything from the current folder to a specified location:

ADD . /go/src/deligo

the golang image hierarchy root is at /go, so this is where i place my stuff in my image too

now, i recently was bothered a bit for mainenance, so i started using glide (https://github.com/Masterminds/glide/) which seems a nice way for dependencies management, until golang team comes up with a native solution - if ever.
so we need to grab and install glide, and from then on we will build throuh this tool

RUN go get github.com/Masterminds/glide
RUN go build github.com/Masterminds/glide

actually this of course is not needed, if we want to only export the executable 'deligo' - for which the ADD command would've been enough, but since this is an exercise in docker lets have as many even redundant steps as bearable.

if we want to do (or rather RUN) something in a different folder we can get away with something like

RUN cd src/deligo && [some command]

but the nicer way to do it is with

WORKDIR src/deligo

which of course changes the current folder temporarily

next  we'll use glide to check what is in its glide.yaml file and download and setup dependent libraries:

RUN GO15VENDOREXPERIMENT=1 glide install
RUN GO15VENDOREXPERIMENT=1 go build

i didn't bother to setup the proper enviroment variable for this test, so i'm adding it to the command line; glide needs this so go tools are aware that we're using the new (for go 1.5) vendor approach to dependencies

finally we must tell docker what to start when the image is loaded.
remember that the value of docker is its container-ness (aahem). i.e. it is meant to run a service in a container.
of course you can run as many services in a container as you like, but really for decoupling one container=one service is probably preferable

so...

ENTRYPOINT ["./deligo"]

if you want to check how your image was built, you can comment the above and instead

ENTRYPOINT /bin/bash

which will allow you to look around and test the new environment as much as you like, but this will require to rebuild the image in order to enable the true entry point after testing

the better way is to override the entry point when starting the docker image:

docker run -t -i --entrypoint /bin/bash deligo

so after you're done exploring justrun

docker run -t -i deligo

 which will start the image with the assigned entry point

ah, lets not forget the build step prior to running, which is...ta-daaa!:

docker build --rm -t deligo .

"--rm" will auto-remove some temporary containers build during construction of our image

so this is all about this short intro to docker.
as always i'm writing this to document my own efforts, so i don't have to go searching too far for these steps :)

anyway, hope it be helpful for somebody else too - next stop: Heroku!

chaooo

simple BroadcastReceiver for Android missed calls app + tips for remote/wireless debuging on the phone

i wanted to play a bit with Android programming (again), so first i decided to try the latest AndroidStudio. I was originally Android-ing on Eclipse and gave only a quick test to the then-new AndroidStudio (neg, mostly because of Gradle probs, i think).
Now I see much has changed, AndroidStudio is very stable and doesn't get in the way - at all - even helping quite a bit.
The best improvement in the Android development environment, for me - and i don't know if it is nothing new - is the ability to run/test and debug (!) remotely - in my case wirelessly - on an actual physical device.

so no slooow Android emulator, no genymotion (which is actually good) - just write your code, immediately deploy/run/test/debug on a real device - so good!
basically what you have to do is plug the phone via usb and type

./adb tcpip 5555

then ask nicely adb to connect to your device (you must know the IP by which the device is connected to your same network, for example 222.778.1.21, but more likely something like 192.168.0.301):

./adb connect 222.778.1.21:5555

then unplug the phone, check if adb sees it via:

./adb devices

and off you go - start run/debug in AndroidStudio and select your phone/tablet/watch/car whatever from the list

this article helped a lot to clear this out - www.jessechen.net/blog/debugging-your-android-app-wirelessly-on-an-android-smartphone/

note that i don't think you actually need the apps that run your phone mentioned in this article, since it seems they only serve to show the IP of your device, which can be retrieved in other ways
 

coding the app itself was easy, except for a bug i made in the end, which caused some &^#$%&$^%$:
i open a cursor into the handy CallLog.Calls, but immediately did moveToNext(), which was jumping to the wrong record....blast.

i didn't bother for UI for the app, since everything is done behind the scenes with BroadcastReceiver and AlarmManager.
Programming was fun, there is so much info on the net that for simple things everyone should be able to write himself nowadays, programming is really quickly turning into a household skill so to say :) oh, what the future will bring with the internet of things!


just to get a glimpse of the code and approach:

we set a BroadcastReceiver for android.intent.action.PHONE_STATE and when notification arrives, we plug a listener into the call state and in its onCallStateChanged try to determine if the call was answered or not.
Then we set an alarm with AlarmManager and then we define a new receiver for the alarm event.
Now this is where we turn "professional" since the user might have reviewed the missed calls before the alarm rang, so we have to check this first, before ringing any bells for missed calls that the user is already aware of.

How? By opening the log and checking the status of missed calls - there is a flag "NEW" which is 1, if the user had not acted on the system missed calls notification, so we check if any of the call records in the log have this set, if yes - we play our own notification and set a new one, which will follow the same path of logic.
There is also another interesting flag/field there: IS_READ, but it seems it is set to 1 only when user acted on the call specifically, like calling back, from what i could gather. In any case flag new proved to be the reliable one.

i actually pushed the new product to github at https://github.com/esdee-git/Micalls, and might even try to push it to Google Play store, just to get a feel of the experience

"Do Something!" with Go, JQuery and Delicious api

it is best when learning a new programming language to exercise on some practical problem.
well, one problem i have is having to put up with plugins for delicious, so i decided to write a server to which to send link information and which in turn would use delicious' api and add new link.
the half-baked, but working version of this i posted at https://github.com/esdee-git/deligo.
it was a good exercise with go, and wiring it with bootstrap and jquery in the frontend - good, fun stuff.
some points to take from this..
go is a fine language to write in, even for prototypes for which i had special place reserved for python.
definitely the creators of the language limited it to specific needs, yet it is a powerful language - at least from my humble experience with it.
on the other pole - bootstrap is quite handy and it was high time i got touch of real jquery

overall - i finally managed to follow two mantras: "do something" and "finish something", so this might be a good start to develop something bigger and better

salut!

playing with GO and setting up Atom for golang

i thought it might be good idea to make my first steps with Go (or is it GO?) in an IDE, so after a quick search i decided i don't want to go as far as eclipse and gave a try to LiteIDE.
and, for the first time i needed a tutorial on an IDE. i mean, even eclipse has its quirks, android developer as well, but LiteIDE is totally obscure, no documentation, and unfortunately not much info - so what does the developer think to gain some audience for this otherwise nice looking tool?

so on we go - to Atom.
i used Atom before in various environments so that was an easy decision.
to utilize Go here you need go-plus extension for Atom.
But after i installed it, it spit some error messages:

GOPATH: Not Set (You Should Try Launching Atom Using The Shell Commands...)

Cover Tool: /usr/local/go/pkg/tool/linux_386/cover

Vet Tool: /usr/local/go/pkg/tool/linux_386/vet

Format Tool (goimports): Not Found

Lint Tool: Not Found

Gocode Tool: Not Found

Godef Tool: Not Found

Gocode Status: Enabled

Oracle Tool: Not Found

ok, lets go one by one:

 GOPATH - thats fine, you export in  (Linux) as prescribed in all Go docs; add it to .profile for persistance. i did, but hadn't login so the setting didn't go into effect

goimports - whatever it does,running "go get golang.org/x/tools/cmd/goimports" installs it

same with The Oracle (whooooo) - go get golang.org/x/tools/cmd/oracle, does it

same with godef - go get golang.org/x/tools/cmd/godef
Ooops, no - now it complains about hg not found; wtf is hg?
ok, installing mercurial took only a few seconds so the souls using it instead of git are forgiven (for now).
ok, but not ok - go get code.google.com/p/rog-go/canvas still spits some crap - apparently google shutting down code.google.com has its side effects on its pet inhouse (gone wild in public) language.
try again with  go get -v github.com/9fans/go spits "no buildable Go source files"

i read some advice on reddit to  mv ../github.com/9fans/ ../9fans.net
but this helped with nothing, and only when i accidentally found an article about godef integration in Sublime, i found a correct path for this crap:
go get -v github.com/rogpeppe/godef

 gocode is flawless at github with go get github.com/nsf/gocode

lint tool you get from here: go get github.com/golang/lint/golint

in fact i see now that this link was very helpful - http://dominik.honnef.co/posts/2014/12/an_incomplete_list_of_go_tools/#golint

now, packaging is cool, but really no body from google, ah sorry - golang - thought about having a centralized hub? a reliable one, like something we can count on not to disappear and devastate time and efforts? blah

ok, going to log off now and see if all these had any effect..

yes indeed!

Go: go1.5 linux/386 (@/usr/local/go/bin/go)

GOPATH: /home/user/work

Cover Tool: /usr/local/go/pkg/tool/linux_386/cover

Vet Tool: /usr/local/go/pkg/tool/linux_386/vet

Format Tool: /home/user/work/bin/goimports

Lint Tool: /home/user/work/bin/golint

Gocode Tool: /home/user/work/bin/gocode

Godef Tool: /home/user/work/bin/godef

Gocode Status: Enabled

Oracle Tool: /home/user/work/bin/oracle

Git: /usr/bin/git

PATH: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/local/go/bin

Atom: 1.0.7 (linux ia32 3.19.0-26-generic)

ok, so now lets see if Atom+Go can do wonders to stun the programming world!


Update: I only played with Atom for 15 minutes when I realized that LiteIDE was actually superbly integrated will Go tools :) so now I do all my Go development in LiteIDE

libgdx and how i solved some problems i had

one has to keep him self busy, so this summer, as being away from the sea, i decided to go back to some android programming.
my initial idea was to create an app, but for UI i wanted to use a gaming framework. with the idea that it will provide me with many shortcuts of building a non-standard UI.

so where to start from?
I had some short experience with cocos2d and wanted to try something new. Unity seems to heavy-weight for my needs, so i flirted a bit with some of the complete tools, namely - GameSalad.
But it only lasted a few hours.

my developer self needed something more hands-on and then i read about libGdx.
So far i have great experience with it - setting it up is flawless, and the ability to immediately run on several platforms is, well, priceless.

the basic tutorial on the wiki gives good idea of what can be done, and there are some awesome other tutorials to hook input, physics (through box2d), graphics and gameplay:
* William Mora's A Running Game with libGDX give an excellent platform, code structure wise.
* the possibility to look in the code of an actual successful game, with full workflow comments, is priceless - many thanks to TheInvader360 for this
* the box2d tutorials from iforce2d were very deep and totally useful
* and of course the endless source of knowledge that is stackoverflow

sooo...i mixed it all in and went to the game that will conquer the gaming world.
one of the unique features would be that the user will swipe things from the screen with his fingers.

so i added the ActionGestureListener, hit Run and went clicking on my Actor, awaiting the debug messages in the console indication it has been hit.
but those messages never came.

alright...let see...Willam Mora's tutorial is very well structured - you have UserData, tied to Box2d bodies, added to the GameStage, twisting in the GameScene.
visually i hadn't implemented any sprites, relying on the wireframes to ensure the gameplay before adding any visual stunners.
and what i was seeing was some boxes moving around, firing things in the air and the box that i should be moving with fingers slowly descending. and not reacting in any way to my touch downs

ok, lets debug and see why touch events don't reach my Actor.
i hook into GameStage touchDown and eventually notice that it doesn't propage the event to the appropriate Actor.
Ah! so this is a bug in libGdx!
lets dig one more time, just a little deeper....wait, deciding whether Actor is hit checks some strange values...this cant be real, right? why my Actor has zeros for x, y; and for width, height as well?
definitely a bug in libGdx, and maybe in Box2d as well...crappy open source...or may be not?

box2d is actually doing all right - the bodies are moving around, falling as they are supposed to - magically and due to this amazing lib. so it is something about the Actor maybe?

then it hits me that the Actor x,y were only set initially at start and while box2d is doing all moving, it doesn't know about my actor, which is living in the libGdx world and i should be taking care of this myself.
alright - lets set the position of the actor.
where? this has to be in stage::update since this is where the code lands on every frame and every box2d step.
ok, but values to set the position to?
one of the biggest and most important advices is the keep everything in the same metric system. you see - box2d works and calculates in meters and kilograms as it tries to simulate the real world, while libGdx of course is more of a graphics library and so it needs to represent things in pixels.

so inevitably there will be problems transforming from box2d world to libgdx (screen/window) world.
so the actor is strictly tied to box2d bodies and in a way it also must live in box2d world, so its position x,y must be in box2d coordinates (usually floats).

at the same time the actor represent a screen entity - on screen it will be some sprite/picture and will need to react maybe to keypress, touch events. so these coordinates must somehow be related to the screen/pixel  coordinates. not to mention that keypress/touch events will send integer x,y to our handlers.

well, libGdx provides the invaluable unproject method. in the first versions of libGdx it was used via the camera, but later viewports were introduced and it should be access from there:

getViewport().unproject(touchPoint.set(x,y, 0));

the idea here is that touch/mouse events are received in screen coordinates - that is absolute x, y, according to the operating system, and the above unproject converts those to world coordinates - that is the world as libGdx sees it.
BUT
this is not enough!
libgdx coordinates are, simply put - integers - pixel coordinates, while our actor lives more in the box2d world; he's coordinates are more like (10f, 17f), while a mouse coordinates will be (339, 400).
luckily libgdx takes all this into account and if you debug into touchDown/hit you will see that the engine at each point converts to more and more specific coordinates in order to find the ultimate actor hit: screen to world, then world to stage and eventually parent to local; local being the coordinates with the shape bound to our body and to our actor's (rectangle?).

this is why it is very important to keep the actors' coordinates up current with the position of the box2d body.

but how to also keep them current in terms of positioning within the libgdx world?

for this the set up of the world must be created with box2d in mind:
say let the desired dimensions of screen are 800x480, then it would be nice box2d world to be 20f x 12f - notice the pixels and float dimensions - anyway, this gives us a nice ratio of 40 (800/20f) which is what we will use to convert actor's coordinates to world coordinates - so if the body is at (11f, 9f) and these are also actor's coordinates in box2d space, when we want to draw our actor's sprite, roughly what we need to do is multiply by the ratio above, giving us (440, 360) in libgdx coordinates - i'm not taking into account here center of object, width, height etc.

and now i notice that i wrote so much that this is turning into a small novel of my libgdx incompetence so it is about time i stopped.

hope this may help someone (as long as he/she's strong enough to read till the end...)