Considering that AIMA has functions to return the actions/instrumentation followed for a given problem, is there a way to get a list of expanded nodes, or the states which led to the problem's solution? I've scoured the source code and couldn't find much. If anyone has worked with this framework in the past and feels like helping, that'd be great.
(Clarification: AIMA means the textbook Artificial Intelligence: A Modern Approach.)
In aima-python, the Node class has a path() method returning the path to reach it from the initial state. Probably aima-java, etc., have something similar.
Related
I see that since version 12, NodeJS has had a recursive option on the fs.rmdir function to allow removal of non-empty directories from the file system. Why is this feature marked "experimental" in the documentation? Does it work or doesn't it? The documentation doesn't say what level of concern to have over this, or under what circumstances.
I found Christopher Hiller's article explaining the difficulties that went into creating an efficient implementation of this, but he doesn't explain the "experimental" designation. Maybe the problem isn't that it doesn't work, or doesn't always work, but that it can be a bottleneck under certain circumstances? I'm trying to decide whether to depend on it or not, rather than writing my own code that's going to have exactly the same pitfalls Hiller encountered, so if anyone here has any insight, I'd appreciate it!
Viewflow sounds like a really useful library, but I've spent two days reading everything I can about it and still don't have a good idea of how to use it.
The current documentation seems to cover
The problems that viewflow is intended to solve
Some very basic examples
In-depth details of its various components.
What seems to be missing is the area between two and three. So I'm looking for something that gives a certain amount of detail and explains viewflow's overall structure while also explaining how things are being done and how one might do something differently if one wanted to.
Does anyone know of any tutorials or documentation that could help to fill this gap? Viewflow certainly sounds great but at the moment, I'm a long way from finding it usable.
I recently came across this website on http://nkwiatek.com/ and it totally blew my mind. How does someone begin to program something like that smokey/fluid effect? Another thing that I can't even begin to conceptualize is a visualizer for a music program.
I only have two years of programming experience on my back but I believe I can see (well, at least I think I can) the vague ideas behind code that goes into various programs and what those programs require. However, programs that create abstract visual renderings (for lack of better words), such as the site I linked to or visualizers, completely baffle me when I try to think of how something like that is done.
For an answer, I'm looking for a pretty high level definition of the program, but low enough that it includes coding concepts and ideas that I can further research.
Because this question isn't exactly as 'concrete' as some of the other questions on this site, an appropriate answer might include:
Thought process of the coder (what you imagine is happening in abstract visual code/high level definition of the code)
API's
Psuedocode
Source code
Links to content that explains topics similar to this
However, these are just guidelines to the type of answer I'm looking for. Just keep in mind, I am not interested in that site alone, but more of the coding ideas and concepts behind the abstract visual programs. I hope I made sense of what I am confused/interested in. I will gladly clarify if anyone has questions on what I am asking. Thank you in advance for your replies!
Edit: To further define the ideas that I am interested in, here is an article on an interesting visual rendering: http://www.iquilezles.org/www/articles/warp/warp.htm
For the nkwiatek.com example, I would start like that:
Create some JavaScript function that makes characters follow the mouse. It could be for example a simple shape like that at first:
OOO
OOOOO
OOOOO
OOO
Once this is working, make it leave a trail and keep a reference to each characters that's been added to the screen (will be needed later)
Now make each generated character semi-random and use the previously mentioned reference to constantly update the characters on screen. The further away a character is from the mouse, the smaller it should look. i.e. characters near the mouse could be "big" like AMHIJKL, etc. characters further away could be smaller like -~=, etc. and ., etc. for the most further away.
This should already make a nice animation. After that, I think there's some function that makes everything move in a kind of wave. It seems to be based on the velocity of the mouse. Maybe there's some research paper on how to generate such an effect.
That is one amazing background.
How to start? Go to the web page and hit Ctrl+U. It's Javascript, so the source is right there. From that... study. The guy's code looks pretty clear, but of course what he's DOING is complicated so it will take some time. Time well spent, I'd think.
Higher-level things like what the guy was thinking... you'll know that after studying the 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
What are some ways in which I can write code that is easily modified?
The one I have learned from experience is that I almost always need to write one to throw away. That way I have developed a sense of the domain knowledge and program structure required before coding the actual application.
The general guidelines are offcourse
High cohesion, low coupling
Dont repeat yourself
Recognize design patterns and implement them
Dont recognize design patterns where they are not existing or necassary
Use a coding standard, stick to it
Comment everyting that should be commented, when in doubt : comment
Use unit tests
Write comments and tests before implementation, that way you know exactly what you want to do
And when it goes wrong : refactor, refactor, refactor. With good tests you can be sure nothing breaks
And oh yeah:
read this : http://www.pragprog.com/the-pragmatic-programmer
Everything (i think) above and more is in it
I think your emphasis on modifiability is more important than readability. It is not hard to make something easy to read, but the real test of how well it is understood comes when someone else (or you) has to modify it in repsonse to changing requirements.
What I try to do is assume that modifications will be necessary, and if it is not really clear how to do them, leave explicit directions in the code for how to do them.
I assume that I may have to do some educating of the reader of the code to get him or her to know how to modify the code properly. This requires energy on my part, and it requires energy on the part of the person reading the code.
So while I admire the idea of literate programming, that can be easily read and understood, sometimes it is more like math, where the only way to do it is for the reader to buckle down, pay close attention, re-read it a few times, and make sure they understand.
Readability helps a lot: If you do something non-obvious, or you are taking a shortcut, comment. Comments are places where you can go back and refactor if you have time later. Use sensible names for everything, makes it easier to understand what is going on.
Continuous revision will let you move from that first draft to a better one without throwing away (too much) work. Any time you rewrite from scratch you may lose lessons learned. As you code, use refactoring tools to eliminate code representing areas of exploration that are no longer needed, and to make obvious things that were obscure. The first one reduces the amount that you need to maintain; the second reduces the effort per square foot. (Sqft makes about as much sense as lines of code, really.)
Modularize appropriately and enforce encapsulation and separation of logic between your modules. You don't want too many dependencies on any one part of the code or that part becomes inherently harder to understand.
Considering using tried and true methods over cutting edge ones. You give up some functionality for predictability.
Finally, if this is code that people will be using before and after modification, you need(ed) to have an appropriate API insulating your code from theirs. Having a strong API lets you change things behind the scenes without needing to alert all your consumers. I think there's a decent article on Coding Horror about this.
Hang Your Code Out to D.R.Y.
I learned this early when assigned the task of changing the appearance of a web-interface. The code was in C, which I hated, and was compiled to a CGI executable. And, worse, it was built on a library that was abandoned—no updates, no support, and too many man-hours put into its use to change it. On top of the framework was a disorderly web of code, consisting of various form and element builders, custom string implementations, and various other arcane things (for a non-C programmer to commit suicide with).
For each change I made there were several, sometimes many, exceptions to the output HTML. Each one of these exceptions required a small change or improvement in the form builder, thanks to the language there's no inheritance and therefore only functions and structs, and instead of putting the hours in the team instead wrote these exceptions frequently.
In my inexperience I was forced to change the output of each exception, rather than consolidate the changes in an improved form builder. But, trawling through 15,000 lines of code for several hours after ineffective changes would induce code-burn, and a fogginess that took a night's sleep to cure.
Always run your code through the DRY-er.
The easiest way to modify a code is NOT to write code. Write pseudo code not just for algo but how your code should be structured if you are unsure.
Designing while writing code never works...for me :-)
Here is my current experience: I'm working (Java) with a kind of database schema that might often change (fields added/removed, data types modified). My strategy is to parse this schema and to generate the code with apache velocity. The BaseClass generated is never modified by the programmer. Else, a MyClass extends BaseClass is created and the logical components of this class (e.g. toString() ! )are implemented using the 'getters' and the 'setters' of the super class.