We Keep Coding

Online java applet that reads and writes from/to a mySQL database?

I'm considering creating a little chatbot that learns from users, similar to Clever-Bot (but very different in the way it learns), but I need a way to interface whatever language I use, with mySQL.
I was thinking that java would be the smarter option, though after hunting around it seems a bit difficult to integrate it with a server. Is this true? If not, how would I go about doing that?
Otherwise, would it be smarter to use JavaScript/jQuery/PHP? I'm quite good with these and haven't got a whole lot of experience with Java (but it would be good practise).
Thoughts?

For creating chat bots, consider AIML. And an interpreter that would help you use your AIML files. Going for a backend database isn't a good thing I would say, since AIML is built for Artificial Intelligence stuff,chat bot in your case. Most of the famous chat bots on the Internet use AIML, example A.L.I.C.E .

Creating a Digital Audio Workstation

I am trying to write my own DAW, mostly just to learn about the mathematics of how signals are processed to get effects, but also for fun. (A rather large undertaking, but I have the time at the moment). I would like for it to work something like Propellerhead's Record as in the rack especially.
I'm running on a Mac, so I'm thinking of using Audio Units for the different parts, then Core Audio for the scaffolding parts. So, the whole thing would be written in C or Obj-C.
However, I haven't used either Audio Units or Core-Audio before, and the internet hasn't been any help for learning.
Does anyone know where I could learn about these?
Or would Java (The only other language I'd feel comfortable using) be better, or is there something I've completely missed while trying to find the "easy" way to do this?
Thanks,
Jon

if you want to write a DAW:
at minimum, get your feet wet with an existing project. if i were to personally choose a project, i'd contribute to Ardour.
the signal processing in a DAW is relatively simple. you'll have to work with mixers, files, and graphics. if you're already comfortable writing apps, then you probably won't learn much (beyond the basics). of course, you could find an existing project and extend it with features which relate to what you want to learn; you could write plugs or visualizations for it.
if prefer to work with signal processing:
AU or VST plugins will be a good intro - there are many existing projects which you may reference. eventually, you'll get tired of waiting for a host to load to test your program.
language:
objc is not usable for realtime audio rendering.
java is very unusual for this application. there are actually wrappers for AUs and CoreAudio... but can't name one commercial Java AU for OS X.
most audio shops (that I know of) are using C++ - not C. (Hardware is different). this really seems like an odd omission from your list - most DAWs and plugins use C++, and that is the language you'd find the most examples in. if you're already comfortable with C and Java, I'd recommend coming to terms with C++ because that's the standard language in the industry when targeting desktops.

Look at the cross platform C++ library JUCE, it is open source with the option to license the code (price isn't bad).
Plenty of professional DAW and VST developers use it, I'm one of em.
https://www.juce.com/
Warning, this library is a lot of fun to play with. It renewed my interest in C++, which was no small feat.

you are right-on in assuming that core-audio and audiounits could form the basis for a system (that may not need to be a fully-fledged DAW but may have some combination of multi-track audio recording, editing, playback, etc...) much easier than worrying about cross-platform concerns, massive all-encompassing frameworks like Juce, or ASIO and other os-bypassing hacks. i think you will find that audio programming is a specialized discipline and most folks here on stackoverflow are ill prepared to offer useful advice.
Java is rather unsuitable, as is C#, as are interpreted languages FOR AUDIO, in particular for multichannel audio, DSP, etc. due to time contraints and the need to work on a rather low-level for many critical loops.
you will find the documents you need on developer.apple.com (you'll have to make a login) and you can find shell-examples for your interest directly inside of xcode examples...
good luck

Information Gathering on Dynamic Website Building & choosing its Architecture

I wanted to build a dynamic Website. The Architecture that I am planning to have is Linux+Apache+MySQL+JSP/Java/Servlets. I have heard a great deal about LAMP stack, but i dont know PHP. Please cite some differences between the two architectures in terms of scalability, security, code re-use, and stuff etc.
Also, having said all this, i need to know where could i get started from. any case-study that could give me an insight as to how to go about building a complete dynamic website.
Thanks.

The short answer is: Architecture isn't about languages, it is about usages. You can make a really slow, non-scalable, insecure, kludgy mess of java just as easily as PHP.
That said.
PHP is a traditionally less structured language. It is not type safe, and that is a double-edged sword, not a negative. My advice, as always, is to stick with what you know for anything mission critical. But if you want to fool around with PHP, the best way is to install it and start playing.
Good resources are this site, and php.net. And google. PHP has a huge hacker culture around it, you'll find loads of info about just about every possible topic. Good, bad, and all in between.
EDIT::
One thing I would do is avoid learning a framework first. Learn raw, un-cut PHP first.

what are java executable format both in unix and windows

I know about class/jar executable format. But jar/class can not ensure source security, because java source code(.java) can retrieve from it. I am looking for such a format where source are secure/un-retrievable.

You can't make code secure from reverse engineering. If one has permission to execute it, then it can be examined where it can be disassembled, reverse compiled, or matched against known assemblies.

If your computer can run it, then you can reverse-engineer it. There is no way to avoid this. The best you can hope for is to stop casual cracking by (for example) passing your source through an obfuscater before compiling.
IBM did this with their type-4 JDBC drivers and it makes it hellishly difficult to understand what's going on (right up until the point you write a program that can de-obfuscate it although you still need to add information back in like function and variable names, no easy task).
Security through obscurity never works against a determined foe. This is the same as with physical security. You can put as much security in your house as you like, and that will prevent casual break-ins, but it will not stop a determined burglar.
I would rather concentrate on doing what I do best, providing top-notch quality software. Most attempts to secure code (beyond simple obfuscation) almost always disadvantages your real customers more than your attackers. Is your code really so precious that you want to risk that?

Python, PyTables, Java - tying all together

Question in nutshell
What is the best way to get Python and Java to play nice with each other?
More detailed explanation
I have a somewhat complicated situation. I'll try my best to explain both in pictures and words. Here's the current system architecture:
We have an agent-based modeling simulation written in Java. It has options of either writing locally to CSV files, or remotely via a connection to a Java server to an HDF5 file. Each simulation run spits out over a gigabyte of data, and we run the simulation dozens of times. We need to be able to aggregate over multiple runs of the same scenario (with different random seeds) in order to see some trends (e.g. min, max, median, mean). As you can imagine, trying to move around all these CSV files is a nightmare; there are multiple files produced per run, and like I said some of them are enormous. That's the reason we've been trying to move towards an HDF5 solution, where all the data for a study is stored in one place, rather than scattered across dozens of plain text files. Furthermore, since it is a binary file format, it should be able to get significant space savings as compared to uncompressed CSVS.
As the diagram shows, the current post-processing we do of the raw output data from simulation also takes place in Java, and reads in the CSV files produced by local output. This post-processing module uses JFreeChart to create some charts and graphs related to the simulation.
The Problem
As I alluded to earlier, the CSVs are really untenable and are not scaling well as we generate more and more data from simulation. Furthermore, the post-processing code is doing more than it should have to do, essentially performing the work of a very, very poor man's relational database (making joins across 'tables' (csv files) based on foreign keys (the unique agent IDs). It is also difficult in this system to visualize the data in other ways (e.g. Prefuse, Processing, JMonkeyEngine getting some subset of the raw data to play with in MatLab or SPSS).
Solution?
My group decided we really need a way of filtering and querying the data we have, as well as performing cross table joins. Given this is a write-once, read-many situation, we really don't need the overhead of a real relational database; instead we just need some way to put a nicer front end on the HDF5 files. I found a few papers about this, such as one describing how to use [XQuery as the query language on HDF5 files][3], but the paper describes having to write a compiler to convert from XQuery/XPath into the native HDF5 calls, way beyond our needs.
Enter [PyTables][4]. It seems to do exactly what we need (provides two different ways of querying data, either through Python list comprehension or through [in-kernel (C level) searches][5].
The proposed architecture I envision is this:
What I'm not really sure how to do is to link together the python code that will be written for querying, with the Java code that serves up the HDF5 files, and the Java code that does the post processing of the data. Obviously I will want to rewrite much of the post-processing code that is implicitly doing queries and instead let the excellent PyTables do this much more elegantly.
Java/Python options
A simple google search turns up a few options for [communicating between Java and Python][7], but I am so new to the topic that I'm looking for some actual expertise and criticism of the proposed architecture. It seems like the Python process should be running on same machine as the Datahose so that the large .h5 files do not have to be transferred over the network, but rather the much smaller, filtered views of it would be transmitted to the clients. [Pyro][8] seems to be an interesting choice - does anyone have experience with that?

This is an epic question, and there are lots of considerations. Since you didn't mention any specific performance or architectural constraints, I'll try and offer the best well-rounded suggestions.
The initial plan of using PyTables as an intermediary layer between your other elements and the datafiles seems solid. However, one design constraint that wasn't mentioned is one of the most critical of all data processing: Which of these data processing tasks can be done in batch processing style and which data processing tasks are more of a live stream.
This differentiation between "we know exactly our input and output and can just do the processing" (batch) and "we know our input and what needs to be available for something else to ask" (live) makes all the difference to an architectural question. Looking at your diagram, there are several relationships that imply the different processing styles.
Additionally, on your diagram you have components of different types all using the same symbols. It makes it a little bit difficult to analyze the expected performance and efficiency.
Another contraint that's significant is your IT infrastructure. Do you have high speed network available storage? If you do, intermediary files become a brilliant, simple, and fast way of sharing data between the elements of your infrastructure for all batch processing needs. You mentioned running your PyTables-using-application on the same server that's running the Java simulation. However, that means that server will experience load for both writing and reading the data. (That is to say, the simulation environment could be affected by the needs of unrelated software when they query the data.)
To answer your questions directly:
PyTables looks like a nice match.
There are many ways for Python and Java to communicate, but consider a language agnostic communication method so these components can be changed later if necessarily. This is just as simple as finding libraries that support both Java and Python and trying them. The API you choose to implement with whatever library should be the same anyway. (XML-RPC would be fine for prototyping, as it's in the standard library, Google's Protocol Buffers or Facebook's Thrift make good production choices. But don't underestimate how great and simple just "writing things to intermediary files" can be if data is predictable and batchable.
To help with the design process more and flesh out your needs:
It's easy to look at a small piece of the puzzle, make some reasonable assumptions, and jump into solution evaluation. But it's even better to look at the problem holistically with a clear understanding of your constraints. May I suggest this process:
Create two diagrams of your current architecture, physical and logical.
On the physical diagram, create boxes for each physical server and diagram the physical connections between each.
Be certain to label the resources available to each server and the type and resources available to each connection.
Include physical hardware that isn't involved in your current setup if it might be useful. (If you have a SAN available, but aren't using it, include it in case the solution might want to.)
On the logical diagram, create boxes for every application that is running in your current architecture.
Include relevant libraries as boxes inside the application boxes. (This is important, because your future solution diagram currently has PyTables as a box, but it's just a library and can't do anything on it's own.)
Draw on disk resources (like the HDF5 and CSV files) as cylinders.
Connect the applications with arrows to other applications and resources as necessary. Always draw the arrow from the "actor" to the "target". So if an app writes and HDF5 file, they arrow goes from the app to the file. If an app reads a CSV file, the arrow goes from the app to the file.
Every arrow must be labeled with the communication mechanism. Unlabeled arrows show a relationship, but they don't show what relationship and so they won't help you make decisions or communicate constraints.
Once you've got these diagrams done, make a few copies of them, and then right on top of them start to do data-flow doodles. With a copy of the diagram for each "end point" application that needs your original data, start at the simulation and end at the end point with a pretty much solid flowing arrow. Any time your data arrow flows across a communication/protocol arrow, make notes of how the data changes (if any).
At this point, if you and your team all agree on what's on paper, then you've explained your current architecture in a manner that should be easily communicable to anyone. (Not just helpers here on stackoverflow, but also to bosses and project managers and other purse holders.)
To start planning your solution, look at your dataflow diagrams and work your way backwards from endpoint to startpoint and create a nested list that contains every app and intermediary format on the way back to the start. Then, list requirements for every application. Be sure to feature:
What data formats or methods can this application use to communicate.
What data does it actually want. (Is this always the same or does it change on a whim depending on other requirements?)
How often does it need it.
Approximately how much resources does the application need.
What does the application do now that it doesn't do that well.
What can this application do now that would help, but it isn't doing.
If you do a good job with this list, you can see how this will help define what protocols and solutions you choose. You look at the situations where the data crosses a communication line, and you compare the requirements list for both sides of the communication.
You've already described one particular situation where you have quite a bit of java post-processing code that is doing "joins" on tables of data in CSV files, thats a "do now but doesn't do that well". So you look at the other side of that communication to see if the other side can do that thing well. At this point, the other side is the CSV file and before that, the simulation, so no, there's nothing that can do that better in the current architecture.
So you've proposed a new Python application that uses the PyTables library to make that process better. Sounds good so far! But in your next diagram, you added a bunch of other things that talk to "PyTables". Now we've extended past the understanding of the group here at StackOverflow, because we don't know the requirements of those other applications. But if you make the requirements list like mentioned above, you'll know exactly what to consider. Maybe your Python application using PyTables to provide querying on the HDF5 files can support all of these applications. Maybe it will only support one or two of them. Maybe it will provide live querying to the post-processor, but periodically write intermediary files for the other applications. We can't tell, but with planning, you can.
Some final guidelines:
Keep things simple! The enemy here is complexity. The more complex your solution, the more difficult the solution to implement and the more likely it is to fail. Use the least number operations, use the least complex operations. Sometimes just one application to handle the queries for all the other parts of your architecture is the simplest. Sometimes an application to handle "live" queries and a separate application to handle "batch requests" is better.
Keep things simple! It's a big deal! Don't write anything that can already be done for you. (This is why intermediary files can be so great, the OS handles all the difficult parts.) Also, you mention that a relational database is too much overhead, but consider that a relational database also comes with a very expressive and well-known query language, the network communication protocol that goes with it, and you don't have to develop anything to use it! Whatever solution you come up with has to be better than using the off-the-shelf solution that's going to work, for certain, very well, or it's not the best solution.
Refer to your physical layer documentation frequently so you understand the resource use of your considerations. A slow network link or putting too much on one server can both rule out otherwise good solutions.
Save those docs. Whatever you decide, the documentation you generated in the process is valuable. Wiki-them or file them away so you can whip them out again when the topic come s up.
And the answer to the direct question, "How to get Python and Java to play nice together?" is simply "use a language agnostic communication method." The truth of the matter is that Python and Java are both not important to your describe problem-set. What's important is the data that's flowing through it. Anything that can easily and effectively share data is going to be just fine.

Do not make this more complex than it needs to be.
Your Java process can -- simply -- spawn a separate subprocess to run your PyTables queries. Let the Operating System do what OS's do best.
Your Java application can simply fork a process which has the necessary parameters as command-line options. Then your Java can move on to the next thing while Python runs in the background.
This has HUGE advantages in terms of concurrent performance. Your Python "backend" runs concurrently with your Java simulation "front end".

You could try Jython, a Python interpreter for the JVM which can import Java classes.
Jython project homepage
Unfortunately, that's all I know on the subject.

Not sure if this is good etiquette. I couldn't fit all my comments into a normal comment, and the post has no activity for 8 months.
Just wanted to see how this was going for you? We have a very very very similar situation where I work - only the simulation is written in C and the storage format is binary files. Every time a boss wants a different summary we have to make/modify handwritten code to do summaries. Our binary files are about 10 GB in size and there is one of these for every year of the simulation, so as you can imagine, things get hairy when we want to run it with different seeds and such.
I've just discovered pyTables and had a similar idea to yours. I was hoping to change our storage format to hdf5 and then run our summary reports/queries using pytables. Part of this involves joining tables from each year. Have you had much luck doing these types of "joins" using pytables?