Software development woes. Java-based development in particular. Also, philosophizing, architecture, design.
Saturday, February 28, 2015
Last of the month
Whoa: last day of the month again. Happens all the time. I'll just put up a placeholder for now. I want there to be a post every month, and apparently I am not above cheating.
Saturday, January 31, 2015
Ten-minute Soul-selfie.
Ouch, hours left of January, but I only have a few minutes to bring together some bits of text from some drafts I made for a more ambitious post.
I think I may just be succeeding in overcoming the major obstacle to worry-free life: the friction/motivation problem. I have been trying to write a post about motivation in particular, a few drafts are the result. I will probably turn it into a blog post here.
For this post, among other bits and pieces, I made a list of motivators and turn-offs, because my current thinking is that it might be good to self-identify of sorts. Painting yourself in a good corner.
But, I'll just make do with my general principles.
Possible demotivator: seemingly pointless businesses. Immoral or amoral could be an interpretation. Examples: the gaming or gambling industries. Not that I could not work for them, but it'd have to be mostly for the money; short term, unless I would be in dire straits, of course.
Possible motivators: utilitarian stuff. Examples: medical stuff; science, research; bioinformatics; tools like travel planners; knowledge, education; or the super-meta-good of them all: developing computer meta-software, such as developer tools, better databases, etc.
Techical demotivators: high-friction technologies. Impedance mismatches, misadaptations, unsuitable tools. ORM. Slow tests. The common arbitrary project structure. Motivators: the opposite. Well, this actually demonstrates that technologies can really only be friction. You want low friction, small demotivators.
Psychological demotivators: gung-ho-itude. Opinion. Attitude. Pessimism, optimism. Dis-humbleness. Self-evidential, gut thinking. Common sense. Motivational speech, motivational travels, motivational money (besides pay, of course). Paradoxical, huh? Nope. I wrote a draft post to explain this from how I believe creative processes work, but look up recent motivational research that shows this result.
Well, got to be going.
Wednesday, November 19, 2014
ByteArrayOutputStream Checked Exceptions
Just realised...
ByteArrayOutputStream actually doesn't declare 'throws IOException' on the methods it does override. I thought it did, because the method I use all the time, write(byte[]), does declare throws IOException, just to annoy us.
What it could do, but doesn't do, is that it could override the other methods so that you don't have to be annoyed by their declaring throws IOException, even though it will, of course, never throw them.
Checked exceptions...yeah, that experiment turned out great.
----
Update: Here's a variant of FileInputStream which avoids checked exception in try-with-resources; which you could instantiate inside of a utility method, say 'public static FileInputStreamNoce istreamForFile(File srcFile)' wherein you catch FileNotFoundException.
ByteArrayOutputStream actually doesn't declare 'throws IOException' on the methods it does override. I thought it did, because the method I use all the time, write(byte[]), does declare throws IOException, just to annoy us.
What it could do, but doesn't do, is that it could override the other methods so that you don't have to be annoyed by their declaring throws IOException, even though it will, of course, never throw them.
Checked exceptions...yeah, that experiment turned out great.
----
Update: Here's a variant of FileInputStream which avoids checked exception in try-with-resources; which you could instantiate inside of a utility method, say 'public static FileInputStreamNoce istreamForFile(File srcFile)' wherein you catch FileNotFoundException.
public static class FileInputStreamNoce extends FileInputStream {
public FileInputStreamNoce(File file) throws FileNotFoundException {
super(file);
}
/**
* This avoids having to catch checked exception in try-with-resources.
*/
@Override
public void close() {
try {
super.close();
} catch (IOException e) {
// well, I don't know what to do here. Log? Re-throw wrapped inside RTE?
}
}
}
Wednesday, September 24, 2014
In-App Web Browser Security
Don't give 'foreign' credentials to applications/apps. They might steal them. For example, if an app wants you to connect to your Facebook identity in an in-app browser. The information fed to an in-app browser can be read by the application.
http://furbo.org/2014/09/24/in-app-browsers-considered-harmful/
http://inessential.com/2014/09/24/craig_on_in-app_browsers [via]
http://furbo.org/2014/09/24/in-app-browsers-considered-harmful/
http://inessential.com/2014/09/24/craig_on_in-app_browsers [via]
Monday, September 15, 2014
Trying IntelliJ
One or two months ago, I tried the NetBeans IDE. Editing was painfully slow. With reservations for the unlikely possibility that it has something to do with my local environment, I can't understand how you can release something like that.
Now, I'm trying IntelliJ. It has pretty solid key bindings emulating the Eclipse bindings, which is great for trying out your normal activities. It also comes with Subversion built in, which is lucky for me because that is what I use when programming on my own.
With only a subset of my needs tried out, it's looking good. I miss two things so far: the linking of current open file to the file hierarchy, so that it (almost) always shows in the file tree; and, I haven't managed to see output from debugging/running. I fear this might be that IntelliJ won't run code until there are no errors, even in unrelated code, and I couldn't find a setting to allow it. (Or maybe it did start my main(), but I didn't see it?)
Other promising areas, both from seeing it first-hand and reading comments to that effect, is the indexing engine. Haven't tried refactoring yet, which is also important. I hear debugging is also faster, which is good. Eclipse's debugger is OK, most of the time, but sometimes grinds to a frustrating stand-still. I think that is caused by the mis-designed communications protocol, e.g. it will try to send a whole stack trace in one go, which is bad for example in the common scenario of recursion gone infinite. I noticed the option of using 'shared-memory' in the IntelliJ debug settings, which might help (but suspiciously not turned on by default?).
So, in summary, trying out IntelliJ can be recommended for Eclipse users, thanks to the ease of getting into it.
Now, I'm trying IntelliJ. It has pretty solid key bindings emulating the Eclipse bindings, which is great for trying out your normal activities. It also comes with Subversion built in, which is lucky for me because that is what I use when programming on my own.
With only a subset of my needs tried out, it's looking good. I miss two things so far: the linking of current open file to the file hierarchy, so that it (almost) always shows in the file tree; and, I haven't managed to see output from debugging/running. I fear this might be that IntelliJ won't run code until there are no errors, even in unrelated code, and I couldn't find a setting to allow it. (Or maybe it did start my main(), but I didn't see it?)
Other promising areas, both from seeing it first-hand and reading comments to that effect, is the indexing engine. Haven't tried refactoring yet, which is also important. I hear debugging is also faster, which is good. Eclipse's debugger is OK, most of the time, but sometimes grinds to a frustrating stand-still. I think that is caused by the mis-designed communications protocol, e.g. it will try to send a whole stack trace in one go, which is bad for example in the common scenario of recursion gone infinite. I noticed the option of using 'shared-memory' in the IntelliJ debug settings, which might help (but suspiciously not turned on by default?).
So, in summary, trying out IntelliJ can be recommended for Eclipse users, thanks to the ease of getting into it.
Saturday, August 16, 2014
First Database Save/Read Cycle
Just got a test saving an integer, closing database, re-opening, and reading it back working. Whut!
I am implementing a sort of database. Yes, it has to be done; and I have to do it, since apparently it's not been done before -- I mean this way. The simple way; the way based on a simple, versatile foundation.
I believe my reasoning behind this is entirely sound. I'll get back soon with at least some philosophical discussion on why most databases suck, or something more nuanced. It's saturday and dinner-time.
I am implementing a sort of database. Yes, it has to be done; and I have to do it, since apparently it's not been done before -- I mean this way. The simple way; the way based on a simple, versatile foundation.
I believe my reasoning behind this is entirely sound. I'll get back soon with at least some philosophical discussion on why most databases suck, or something more nuanced. It's saturday and dinner-time.
Monday, July 14, 2014
Uh
Wow, two months passed. Let's write something.
So, I haven't been totally idle. Right now I'm just unmotivated and tired of everything, but before that, I was slightly less unmotivated, and spent a week figuring out how to write an allocator for memory mapped bytes. I can't remember what there was to figure out, really. But there's some amount of compromise involved; speed vs size vs simplicity, as always. And the implementation, which is almost done, depending on your definition of done, was fiddlier than expected; as expected. But surprising. Given that I thought I had found an elegant solution. Perhaps I had. Or maybe because programming in Java what should be done in C is not as fun as it sounds. And I am tired.
It's one of these things that you'd think would be easy to find. Well why would I think that, really, am I that demented? Don't you remember that whenever you search the net for an X that you think should exist, all you find is a) stuff that does nothing resembling what you want, b) crap, c) frameworks that do something at least in the ballpark, maybe, or maybe does it in some non-APId component deep inside, but then you would have to work hard for it like one would with a chisel on a block of concrete with a precious marble vase hidden within it, provided that you could even know for a fact that the vase is somewhere in there, d) things for other programming languages, again probably a, b, c, but probably not X? Note that finding a well written, documented solution for X in another language would actually be very useful; I wouldn't mind translating too much, it'd actually be fun, compared to investing time and effort into something that you feel 'ought to' exist. And I am tired or perhaps depressed. Especially something like a memory manager/allocator, since off-heap storage has become rather popular lately in parts of the Java world.
So maybe I'll publish this allocator, or at least a description of the solution, if I can find the energy. As I said, the solution is pretty simple, but the code unfortunately not so simple nor fast. I should optimize and refactor it, after adding more tests. After I try to use it for some small experiments. But I am tired of pretty much everything right now.
I'd like to not be one of the legion of people who put out crap that others find and waste time on and which I'd be ashamed of. If there was a better way to find and filter for library code, it would feel better to release code of mediocre quality. Or one could instead find code of mediocre quality, but appropriate enough to be improved a little, adapted a little, republished, reused. Such a tool would of course be extremely valuable for finding stuff, regardless.
Well blah blah, somebody please make that tool, I'm busy writing blogs.
So, I haven't been totally idle. Right now I'm just unmotivated and tired of everything, but before that, I was slightly less unmotivated, and spent a week figuring out how to write an allocator for memory mapped bytes. I can't remember what there was to figure out, really. But there's some amount of compromise involved; speed vs size vs simplicity, as always. And the implementation, which is almost done, depending on your definition of done, was fiddlier than expected; as expected. But surprising. Given that I thought I had found an elegant solution. Perhaps I had. Or maybe because programming in Java what should be done in C is not as fun as it sounds. And I am tired.
It's one of these things that you'd think would be easy to find. Well why would I think that, really, am I that demented? Don't you remember that whenever you search the net for an X that you think should exist, all you find is a) stuff that does nothing resembling what you want, b) crap, c) frameworks that do something at least in the ballpark, maybe, or maybe does it in some non-APId component deep inside, but then you would have to work hard for it like one would with a chisel on a block of concrete with a precious marble vase hidden within it, provided that you could even know for a fact that the vase is somewhere in there, d) things for other programming languages, again probably a, b, c, but probably not X? Note that finding a well written, documented solution for X in another language would actually be very useful; I wouldn't mind translating too much, it'd actually be fun, compared to investing time and effort into something that you feel 'ought to' exist. And I am tired or perhaps depressed. Especially something like a memory manager/allocator, since off-heap storage has become rather popular lately in parts of the Java world.
So maybe I'll publish this allocator, or at least a description of the solution, if I can find the energy. As I said, the solution is pretty simple, but the code unfortunately not so simple nor fast. I should optimize and refactor it, after adding more tests. After I try to use it for some small experiments. But I am tired of pretty much everything right now.
I'd like to not be one of the legion of people who put out crap that others find and waste time on and which I'd be ashamed of. If there was a better way to find and filter for library code, it would feel better to release code of mediocre quality. Or one could instead find code of mediocre quality, but appropriate enough to be improved a little, adapted a little, republished, reused. Such a tool would of course be extremely valuable for finding stuff, regardless.
Well blah blah, somebody please make that tool, I'm busy writing blogs.
Subscribe to:
Posts (Atom)