JointJS and Extending Devs - jointjs

I'm trying to extend the joint.shapes.devs.Atomic model but get a "maximum call stack size exceeded" error.
This is apparently normal behavior for the devs module. ( see the following link: https://groups.google.com/forum/#!topic/jointjs/md5s_fKPl_M ).
I was wondering if there is a way to work around this? Would it be better to just edit the devs module directly? The solution in the above link won't work for me, since I'll need to be able to convert the data into JSON.
Edit
I've made my own object based on the devs model. I can extend this model as I need to, but I still don't like this as a solution. I don't think it offers the same kind of flexibility with extending as I was looking for. If anyone has a better option please let me know.

Related

Creating a knowledge base in dialogflow with java API

I need to create a knowledge base and add some question/answer data there. I went through this example https://github.com/dialogflow/dialogflow-java-client-v2/blob/master/samples/src/main/java/com/example/dialogflow/KnowledgebaseManagement.java but that apparently just creates an empty knowledge base.
Tried digging through the (very poor) documentation available but found no way to make it actually do something useful.
https://github.com/dialogflow/dialogflow-java-client-v2/blob/master/samples/src/main/java/com/example/dialogflow/DocumentManagement.java
Need to jump through these hoops

Semantics based code search

We have a large number of repositories. We want to implement a semantics(functionality) based code search on those repositories. Right now, we already have implemented keyword based code search in which we crawled through all the repository files and indexed them using elasticsearch. But that doesn't solve our problem as some of the repositories are poorly commented and documented, thus searching for specific codes/libraries become difficult.
So my question is: Is there any opensource libraries or any previous work done in this field which could help us index the semantics of the repository files, so that searching the code becomes easy and this would also help us in re-usability of the codes. I have found some research papers like Semantic code browsing, Semantics-based code search etc. but were of no use as there was no actual implementation given. So can you please suggest some good libraries or projects which could help me in achieving the same.
P.S:-Moreover, companies like Koders, Google, cocycles.com etc. started their code search based on functionality. But most of them have shut down their operations without giving any proper feedback, can anyone please tell me what kind of difficulties they are facing.
not sure if this is what you're looking for, but I wrote https://github.com/google/zoekt , which uses ctags-based understanding of code to improve ranking.
Take a look at insight.io
It provides semantic search and browsing

Obsole warnings using AutoMapper version 4.2.1 and how to solve

According to the occurrence of questions about 'AutoMapper Migraton from static API' lately and the fact I was Exploring Christos Sakell blog 'Building Single Page Applications using Web API and AngularJS', I also came across some obsolete warnings.
/***********************************************************************************
* AutoMapper.Mapper.CreateMap()' is obsolete: 'Dynamically creating maps will be removed in version 5.0.
* Use a MapperConfiguration instance and store statically as needed, or Mapper.Initialize.
* Use CreateMapper to create a mapper instance.
***********************************************************************************/
Completely ignorant of recent changes of AutoMapper (I using this mapping tool for the very first time) I was trying to get rid of those obsolete messages. Searching around I came across two possible solutions:
1) http://quabr.com/36398318/automapper-mapper-createmaptsource-tdestination-is-obsolete , and
2) http://davecallan.com/automapper-4-2-example/#comment-8914
These hints seemed to be pretty straightforward. It turned out tweaking the *MappingProfile classes weren't that difficult, but what to do on several controllers? That was a complete different piece of cake. I got completely lost. I ran in all kind of strange errors not knowing or having a clue what to do. Even the just mentioned blogs weren’t that explanative. More or less, I got the feeling they were keeping the puzzle a live (I'm kidding).
So the question was: how to solve the troublesome mapping from the controller to the *MappingProfile class. Luckily, I found a possible solution, so please tackle it...
I do like puzzling and buzzing around the net, I finally found a combination of hints, and that's what I want to share with you.
The solution for this is a combination of tweaks.
First of all, have a look at page 'Migrating from static API' (https://github.com/AutoMapper/AutoMapper/wiki/Migrating-from-static-API).
Notice the second block right below ‘In 4.2.x and later …’ that’s what is needed on several controllers. Dave Callan just gave a part of the clue. He just forgot a part of the solution. So I asked him to add the missing part to his solution as well.
So, implementing the hint on the 'Migrating from static API' page in combination with the suggestion of Dave Callan (http://davecallan.com/automapper-4-2-example/#comment-8919) block 1: Instantiating a new MapperConfiguration(...) in *MappingProfile class(es), you can get rid of those obsolete warnings: On every cycle proper mapping.
At least, I got rid of those warnings.
What will happend in the nearer future with AutoMapper, hopefully those guys in Austin TX will make proper decisions on this matter.
I also testing the code (block 2 of 'Migration from static API') with the suggestion on Quabr (instead of instantiating a new MapperConfiguration, they suggest to call the Initialize method of the current Mapper). This combination gave my errors like ‘index outside matrix borders’.
Apparently on each cycle the mapping lists are not renewed. This combination of code tweaks resulted (to me) in a ‘no go’. Perhaps others, do not agree with me, fine, at least that’s what I noticed.
My only goal is to help other members who are facing comparable trouble.
I'm pleased to share my solution. Have fun

Resources for learning how to better read code

I recently inherited a large codebase and am having to read it. The thing is, I've usually been the dev starting a project. As a result, I don't have a lot of experience reading code.
My reaction to having to read a lot of code is, well, umm to rewrite it. But I need to bring myself up to speed quickly and build on top of an existing system.
Do other people have techniques they've learned to absorb a code base? At this point, I'm just reading through the code. I've tried generating UML diagrams using UModel. They're so big they won't print cleanly and when I zoom in, I really do lose the perspective of seeing all the relationships.
How have other people dealt with this problem?
Wow - I literally just finished listening to a podcast on reading code!!!
http://www.pluralsight-training.net/community/blogs/pluralcast/archive/2010/03/01/pluralcast-10-reading-code-with-alan-stevens.aspx?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+pluralcast+%28Pluralcast+by+Pluralsight%29
I would recommend listening to this. One interesting point that was made that I found radical and may be something you could try (I know I'm going to!). Download the entire source code base. Start editing and refactoring the code then...throw that version away!!! I think with all the demands that we have with deadlines that doing this would not even occur to most developers.
I am in a similar position to you in my own work and I have found the following has worked for me:
- Write test cases on existing code. To be able to write the test case you need to be able to understand the cde base.
- If it is available, look at the bug\issues that have been documented through the life cycle of the product and see how they were resolved.
- Try and refactor some of the code - you'll probably break it, but that's fine you can throw it away and start again. By decomposing the code into smaller problems you'll understand it bettter
You don't need to make drastic changes when refactoring though. When your reading the code and you understand something, rename the variable or the method names so the better reflect the problem the are trying to solve.
Oh and if you can, please get a copy of Working Effectively with Legacy Code by Michael C. Feathers - I think you'll find it invaluable in your situation.
Good luck!
This article provides a guideline
Visualization: a visual representation of the application's design.
Design Violations: an understanding of the health of the object
model.
Style Violations: an understanding of the state the code is currently
in.
Business Logic Review: the ability to test the existing source.
Performance Review: where are the bottlenecks in the source code?
Documentation: does the code have adequate documentation for people
to understand what they're working on?
In general I start at the entry point of the code (main function, plugin hook, etc) and work through the basic execution flow. If its a decent code base it should be broken up into decent size chunks, and you can then go through and figure out what each chunk of the code is responsible for. Looking back at when in the execution flow of the system its called.
For the package/module/class exploration I use whatever doxygen will generate once its been run over the sources. It generates some nice class relation diagrams, inheritance hierarchies and file dependencies graphs. The benefit of these is they are each focused on a single class and how it ties it with its neighbors, siblings and parents, so the graphs are usually of manageable size and easy to understand.
As you understand what different, classes, functions and sub-systems do I like to add comments to fill what sounds like obviously missing documentation. This helps you when you re-read through the code the second time.
I would recommend another podcast and resources:
SE-Radion episode on Software Archeology

Does anyone know where decent documentation describing the Lucene index format IN DETAIL on the web is?

I am mainly curious as to the inner workings of the engine itself. I couldnt find anything about the index format itself (IE in detail as though you were going to build your own compatible implementation) and how it works. I have poked through the code, but its a little large to swallow for what must be described somewhere since there are so many compatible ports to other languages around. Can anyone provide a decent link?
Have you seen this: http://lucene.apache.org/java/2_4_0/fileformats.html? It's the most detailed I've found.
Although Lucene in Action does stop short of the detail in that link, I found it a useful companion to keep a handle on the big picture concepts while understanding the nitty gritty.

Resources