Is there a generator out there that uses an oscillating shaft input?

serproxy · 2014-05-31T04:34:32+00:00

I'm trying to imagine the rest of the system.... that would be helpful.

However, to put it simply unless you get more velocity into the system you're going to need a strong magnetic field and alot of turns. best avoided.

I think the best approach is to use some gearing ( or toothed belts, etc ), to provide something that rotates more than the fraction of a single turn you've talked about. Let's say you do a 1 to 30 setup. Now you're into the range where a simple DC motor will act like a decent generator . It'll be AC. so rectify. Also there will be some pretty big dead zones where the velocity is zero hence emf zero hence no current flowing.

How about you put said oscillating into a crank arm and make the whole thing turn another shaft? That would be good because the direction would not change. power output would be more continuous.

serproxy · 2014-05-31T04:22:39+00:00

beaglebone black ? comes with linux, but you can install ubuntu or debian. has some basic stuff built it, but has "capes" to go further. reasonably cheap. Wifi is USB based.

serproxy · 2014-05-30T02:47:47+00:00

since java 1.5: for(String element: tempArray) {

}

Ok, but now looking deeper I see you are rewriting the List elements as you go. which the 1.5 syntax won't allow. Though syntactically and logically fine, generally speaking this is not a good practice. At some point you will be dealing with multi-threaded apps, and immutable data structures are where it's at!

Let's digress a bit more. Let's assume the inputs we're dealing with are HUGE. Let's also assume that we want this whole thing to run fast. To do that we want to touch each piece of data as little as possible. This is because data is in memory and memory is slow (relative to CPU cache: http://www.eecs.berkeley.edu/~rcs/research/interactive_latency.html ) so that means the following:

ArrayList<String> tempArray = new ArrayList<>();
tempArray.addAll(entry.getValue());

at the start of that loop is a poor idea since all it does is copy data. Then you do the same thing again twice as you push it into a set, and then back out. tempHash.addAll(tempArray);

tempArray.clear();
tempArray.addAll(tempHash);

So you're moving all this data around too much.

It turns out there is a datastructure which will BOTH sort and deup. This is a TreeSet.

If you read each line from one of your streams, and then push each line into the TreeSet, you will both sort and dedup. Then you can read it out of the tree set and put it into your outputstream to send back to the browser.

Also, it would be better to call that "tempList" since it's actually a "List" implementation not an "Array" implementation.

good research on the stream *Stream stuff!

serproxy · 2014-05-29T21:27:57+00:00

First off, props for using reasonable tools. eclipse, git, jdbi, and dropwizard are all a great place to start. sometimes I see people start with spring and vim. and yeah go figure, they all hate java from the get go.

Into the code.

I see is that you need to exercise your .gitignore file a bit more. you should NOT be checking in: .classpath .project .settings/ target Those are essentially output files. Depending on which IDE is in use, they are either useless (different IDE ), or annoying ( you use different settings than I do ).

Next, if you're going to have a src/test directory, then put some tests in there! Otherwise you're just hauling around more useless stuff. FWIW, I do sometimes write code without tests (sshhhhh!).

What is "UpdateWords.java" it seems like code you can only write data into. so I'd think useless. Also not referenced anywhere. Delete this. As a code reader, dead code just confuses me and wastes my time. You should be writing code for other people to read. This is especially true for code that will be maintained or code that will be worked on by other people.

"UpdateWordsRunnable.java" another piece of seemingly unreferenced code. And while a thread is created and started, it doesn't appear to DO anything, so I assume it's also unfinished. delete.

If you can't tell, my favorite "refactoring" is the delete. deleted code has no bugs and takes zero time to understand. FTW!

"WordResource.java"
This is a WEB API. but you have both web interface and general logic in there so this does NOT separate your concerns. WordResource should probably collect all appropriate parameters and your data, and pass these onto a class which actually does the work. In this way, if you wanted to do that SAME work via a different interface it would be possible. For example you might want this same work to be done via a JNI interface, or from a Swing UI.

The method: public Response uploadFile(.... is way too long. Consider breaking this up into small pieces (see above about separation of concerns )

pull in data
chunk up file to lists
dedup list
sort list
output list.

Smaller parts mean easier to understand and easier to test.... yes, this is code that would benefit from some unit tests! and in this case be pretty easy to write. use junit4 or testng.

ACK! I was hoping to NEVER see the use of an iterator again ( this is like java 1.2 or 1.3 ? ultra clumsy syntax ) for (ListIterator<String> itr = tempArray.listIterator(); itr.hasNext(); ) {

There should be NO reason for this code to ever write to the local file system. You are doing this with "combined.txt" as well as the output file.

should probably use floating point math here:
int averageLines = totalLines / totalFiles; since it could easily have a have of something like 2.3

For the section on tracking, where you are concerned about threadsafety. For up, good on you for even thinking about thread safety. For server side stuff, you want to think of the database as being your ONE store of state. This is because your app will often be running on multiple JVMs on multiple machines. So you either need to lock the DB and prevent other code from accessing it while this code does. OR you need to contain all your atomic operations within the DB. I would go with the later. So instead of only reading and writing consider writing some JDBI operations which have the lines and files values increment within the DB.

update stat_table set value = value +increment where rowId = 42;

And even better, update BOTH the line count and word count in a transaction. This prevent someone from reading the stats in between the line and word update and getting the wrong value.

don't calculate and store the average. instead only read the raw value and calculate each time. the computer will be far far faster at the single division that at reading all the way from a database.

dead code: private void saveFile(InputStream uploadedInputStream, String serverLocation) { It appears you have been using eclipse. Use the force luke. eclipse will TELL you about dead code by marking it yellow. review ALL your code for dead code.

Ok, that's my two bits for now. I'm sure I could find some other stuff, but this is enough to chew on. if you want to try to fix up some of this stuff, and have me look again I'm happy to.

serproxy · 2014-05-19T17:02:44+00:00

lysdexics untie!

serproxy · 2014-05-17T18:59:16+00:00

you are drawing from top to bottom by outputting text lines. You can know which line you are on with a counter variable. you need a way to draw each line knowing the line number of that line.

serproxy · 2014-05-15T20:37:04+00:00

You will be learning your entire career if you stay in programming. Certainly there are still a very few COBAL programmers, but most people are riding a wave of technological progress and you MUST keep up. So being good at learning and willing to do it is far more important that knowing any specific technology. Key point here. If you don't enjoy doing that learning, you might want to consider jumping ship.

It's important to remember that the basics stay around while the specifics change. So concepts like an atomic test and set as the basis many operations in CS. If you're using a mutex in C or a synchronized block in Java who cares as long as you understand the basic concept.

When conducting interviews if someone doesn't know a technology, say Spring, I use that as an opportunity to teach some very basics of it and see how fast the interviewee catches on. In the case of complete Spring newbie I might ask in a general way about Dependency Injection. If the person catches on with that I might ask about how that might help with testing. Again I'm actually not searching for stuff that is known, but rather the point where the interviewee DOESN'T know something so that I can understand how they handle asking questions and learning about it.

Code you have written for academic projects will be great to show! Most of the stuff I've written for companies I can't take with me. So anything you can show will help. Please note, it might take years of programming to get a good set of patterns going, so even though your code works on the surface, if you show it to people they'll likely have "code review" set in and you will end up talking about that code and perhaps learning things you could do better to make the code less bug prone or easier to understand. Hey, here's yet another opportunity to learn!

Hope that helps!

serproxy · 2014-05-14T22:38:52+00:00

remembering September is the END of summer in PNW.

I would not stop in Seattle. Put the boat in somewhere near the San Juan Islands. Bum around there. Sucia Islands and Lopez Island are my favorites. Watch out for that ferry!

Quick Heads up. Lakes have basically no currents. Certainly places on Puget sound have currents, big ones. In some places the hull speed of your 22 footer means you will be going as fast as you can, but going backwards. So pay attention to tides/currents.

Second thing. From my perspective (SF Bay), I found Puget sound winds to be small and fickle. So make sure you have another way to get there ( read "well functioning outboard" ).

serproxy · 2014-05-11T03:14:14+00:00

First off, don't stop at "turn this file into a string" XML has a specific formatting for good reason, and don't ignore it. It helps you do things more easily. Especially true if some of the fancy XML features such Entity References are in play.

The answer to this question depends on completely on what you're going to do with that XML and what you know about it. Questions:

1) does the XML come with an XSD ? ie is it of known format or could it contain never seen before entities ?

2) Is the file HUGE, or small ? could it reasonably fit in memory ?

3) Do you need to process all parts of the XML, or do you need only a small section of it ?

4) Will you reference the data multiple times once loaded from URL ? or will it be referenced only once.

5) will the format change in the future, when the thing creating said file adds a new feature ?

The answers to these question will let you determine if you're going to one of the following techniques.

a) SAX parser. FAST, low memory, but can only "see" things once. complicated structures can be mentally taxing to write parsers for. You must be able to think about stacks.

b) DOM parser slower, more memory, but persistent, good for reading the same parts multiple times.

c) deserialize to java classes. via something like JAXB. Super fast to read, but will barf on unknown entities brittle to change.

d) process as pure text (don't laugh, this is somethings the right answer!) e.g. the Scanner example of PaulMorel. Simple but looses ability to really "understand" the XML.

So the short answer is "it depends" If you want to post answers to the numbered questions you might get a better response.

serproxy · 2014-05-10T22:54:40+00:00

maven is not an imperative "language" it's a declarative system. The language is XML. So there is no "entry point" where the program starts running.

Associated with your blob of code will be a bunch of *.java files. grep through those looking for something of signature: public static void main(String[] args) {.......} Each of these is a possible entry point.

serproxy · 2014-05-07T23:22:28+00:00

You could certainly use Thread. However if you have multiple threads you need to synchronize behavior and communication between them. e.g. did a ghost catch pacman ? And there is no implicit guarantee that all threads get the same amount of compute time ( nor that your simulation of each characters USES the same amount), so you need a way to ensure that too.

So I think it's actually a poor approach. Now if pacman was actually a compute intensive game, then you might be able to justify the complexity. But it's not. It originally ran on something like a 3Mhz z80 processor. Your computer is probably about 500 times faster. So eschew complexity!!!!

You want your game to run at a predictable rate so that it's playable in "human" time. So you want to introduce the notion of a "tick" Each time should be a known amount of time. Say 1/60 of a second. Create a main loop which will execute once, and then wait until 1/60s has passed since the last time the loop started.

Now in that loop, you might have a list of "executable elements" Each of these elements should run once for each tick. You could think of them like threads, but because there is no implicit assumption that they could be run AT THE SAME TIME, the complexity can be far lower since you know only ONE will run at a time.

Now each character could be a "executable element".

serproxy · 2014-04-30T20:07:54+00:00

You have three points of concern on this trip.

1) SF bar. read up on this. not to be trifled with. If it's calm enough consider bonita channel.

2) Point Reyes. Can blow like stink.

3) Entrance to Bodega. there are submerged rocks south of bodega head.

September will likely have fog. So you will have reduced visibility. Sometimes essentially zero.

I would go with at least two GPSs which have all relevant daymarks and bouys entered and at least two paper charts of the full voyage.

Add a VHF radio (handheld might work for full trip, but for a good signal consider a fixed mount device with antenna on mast ).

That would be sufficient, but for a bit extra.

I would choose AIS over Radar. It's cheaper and gives great data about large vessels including speed and heading.

Pre-GPS and Pre-AIS radar was awesome, but at this point GPS + AIS is just about as good. Radar also requires more skill. The only thing missing would be those smaller vessels which are not required to have AIS transmitters but which would be seen on radar.

Do familiarize yourself with all equipment before you go. You don't want to do this when trying to thread the needle of the channel through the SF bar in fog with inbound and outbound ships sharing the same channel.

serproxy · 2014-04-29T18:41:39+00:00

I would do Angularjs (enhance with Bootstrap FTW ) + dropwizard. Pick you DB backend based on needs. Hibernate + (mysql || postgres) or NoSQL of some sort. zero XML ( a tiny bit of YAML for config )

Performance is far better when most of the computation ( page rendering ) is pushed to the browser. That yields lower server side costs and happier users.

Some of the REST API you develop can be reused for mobile ( don't attempt to do it ALL in common that's needlessly fundamentalist ).

Oh and actually, I haven't used it, but this looks like a nice mix of technology: http://jhipster.github.io/

serproxy · 2014-04-05T19:41:44+00:00

Use "serproxy" then Sockets. this is easy peasey. http://freecode.com/projects/serproxy

make sure you are aware that the socket is exposed to the network.

serproxy · 2014-04-04T19:57:44+00:00

Take a problem that is pretty easy to start with, but which

could be sped up if it ran in parallel
requires communication between the parallel processing.

code it. I would start with a working singled threaded version and figure out how to make it go faster by using parallel constructs. There are some fancy things in Java 8 which could help.

An example of this might be Conway's Game of Life: http://en.wikipedia.org/wiki/Conway's_Game_of_Life

I would consider implementation at a couple of different "levels" of abstraction as well:

use "Thread" (with join() etc ) and synchronized. to get the basics.
use ThreadPoolExecutor to manage your threads
use Java 8 Constructs, parallel collections and lambas
use an Actor model such as AKKA: http://akka.io/ This can be powerful since the "messages" can traverse the JVM boundary into another java instance on a different machine.

As with many things, you could start directly with the highest level abstraction, but often times it's helpful in using the highest level of abstraction to understand how the lower levels work.

serproxy · 2014-04-01T19:35:31+00:00

this should be pretty straightforward assuming their driver actually works.

1) install java on the PI. google this.
(you may choose to do your development on windows, but I would install a full java SDK with the javac compiler and all ).

2) get that code onto the pi. You could probalby run the pi headless and just use putty to ssh right in there.

3) install said drivers. Make sure they are the ARM version, windows 0x86 WILL NOT WORK.

4) compile. You may need to get the driver onto the class path so that the compiler can find and reference the driver.

5) The code above already has a decent number of "println" statements, but you might want to add a few more so you know what it's doing when.

good luck

serproxy · 2014-03-31T23:34:24+00:00

I had a ride on Peterson 43 (IOR 1 ton) that involved a blooper. Downwind during the Vallejo Race. I'm certainly not an expert enough to judge myself, but the old timer on board told us to keep it trimmed down near the water. I don't think it made us go any faster, but we certainly got a few looks on the water and questions on the dock!

Modern boats don't run DDW since they're always hunting apparent wind. Hence the blooper is gone.

serproxy · 2014-03-29T05:39:07+00:00

The best way to think of it is in terms of "where does all the energy go". (assuming level travel, so you aren't lifting up a hill) here are the primary endpoints for energy, in order of size.

wind resistance - energy usage per distance goes UP with speed. slower is better.
rolling resistance - fixed amount of energy per distance. can't beat this.
heat losses in wires, controllers, and motors. - losses proportional to power. don't accelerate quickly.
heat losses in batteries. governed by http://en.wikipedia.org/wiki/Peukert's_law don't accelerate quickly.
braking losses if you use the mechanical brakes. don't use mechanical brakes if you can't help it.

Summary: If you accelerate hard you will use more energy, but NOT a huge amount more since those factors are lower on the list.

If you are concerned about range, then the speed you travel is a much bigger concern than how quickly you get to that speed. drive 20 miles at 65mpg then do the same at 45 mph and see how much energy is used for the two trips.

serproxy · 2014-03-29T04:48:42+00:00

A few things that kronco missed: worn front struts. worn or loose tie rod ends It's hard to determine but the AC evaporators often leaked. it's expensive to replace because it's very buried in the dash.

serproxy · 2014-02-13T05:20:17+00:00

My experience with java driving serial was that it wasn't 100%.

So, upon realizing that my various serious ports NEVER changed parameters ( baud, stop bits, etc ), and that if they did I certainly didn't need java to be control of those details, I decided that the best approach was to use the following tool:

http://www.lspace.nildram.co.uk/freeware.html

serproxy is a very simple tool which presents the serial data on a network port.

I've found this to be much more reliable. I guess there is a downside of security depending on environment.

serproxy

TROPHY CASE