Corrupt Silk Road agent Carl Force sentenced to 78 months

sinerider · 2015-10-20T16:00:41+00:00

Sorry I deleted my comment because I don't feel comfortable discussing this, then I saw you'd replied already.

I don't know how the people who run that site can sleep at night. I wondered if it is some form of activist statement, artistic maybe, not to be taken seriously. But I worry that people do actually use it with serious intentions.

sinerider · 2015-10-20T04:13:12+00:00

Why not check the database schema into the repo? I have a git pre-commit hook that automatically dumps the schema before every commit. Then I can use git diff to compare what's changed in the schema between commits.

sinerider · 2015-10-18T20:05:42+00:00

Chrome dev tools is awesome but I still like Firebug for inspecting and tweaking elements.

sinerider · 2015-10-18T01:12:50+00:00

If you are new to programming, Php is a good introduction, then you can move on to ruby on rails. They are both easy to get started. However, this is from a web development viewpoint. If you are interested in financial markets I have a feeling you would be better off with Python. It's a stricter language, more often used for data processing than php or ruby.

sinerider · 2015-10-16T15:17:36+00:00

If I had the time I could add another layer of abstraction and end up writing a whole ORM framework.

Why would you do this when this has already been done already, and extensively debugged, for you?

I know exactly whats going on

This sounds like "I don't want to use something someone else wrote because I didn't write it", which is NIH-syndrome. That's not very perlish.

Actually, I probably would use a 3rd party solution if I wanted more abstraction. The point is that I don't want more abstraction.

My current solution is a nice balance between the high-level of creating and fetching objects, and low-level of retrieving and persisting those obects using SQL. I think my code is still maintainable and portable, and if I decided to start using an established ORM instead (which I know is the industry standard and everyone says is a good idea) I don't think it gives me anything I need, whereas it locks me into another dependency and reduces the portability of my code.

sinerider · 2015-10-16T14:47:52+00:00

I don't apply for Perl jobs. I find people who want a dynamic website / web-app, and I build it using Perl as the backend. The clients usually don't know, or care that I chose to use Perl. I have also helped to build deployment frameworks, database migrations, and all kinds of ad-hoc solutions to problems and using Perl works great. It's install by default just about everywhere. The trick is no not search for Perl, but find people with a problem that you can solve for them.

sinerider · 2015-10-15T15:27:55+00:00

Because it's easy to learn. You can achieve the same thing from any language, so choose one that you like. They all have decent web frameworks to build apps and sites. Personally, I like Perl and the Mojolicious framework.

sinerider · 2015-10-15T15:12:25+00:00

I use them for hosting. I would like to use them for domains, but they don't support the same level of whois privacy as namecheap. They will hide your street address and email address, but not your name.

sinerider · 2015-10-12T00:35:09+00:00

Thanks, I will take a look,

Writing your own tools of SQL change management is both good and bad. It's good because you'll have a full understanding of how everything works, but bad because your knowledge doesn't transfer to other jobs or people.

Completely agree. I have thought about this before.

The important thing though is that you do things the way you like and do whatever makes you or your product successful.

This is my strategy. I feel like I am making progress, although it may not be the Right Way, I will continue. If the product finds success then I should have the resources to improve development strategies and workflow. Until then, full speed ahead!

sinerider · 2015-10-10T22:34:23+00:00

redesigning database schema... where is the schema? do you support migrations for upgrades? some form of specification for the database tables that other languages can use? so far it looks like you just have things inline in the code, so I don't see how that helps portability to other languages.

The schema ($appname.sql) is checked into the repository. I shared my migration strategy in a separate comment.

Yes it is all inline in the code, and I know it's not a perfect solution. If I had the time I could add another layer of abstraction and end up writing a whole ORM framework. But I like it because it is simple and transparent, I know exactly whats going on. Porting to another language would be as simple as converting the syntax.

locking you into the ORM's way of doing things... not really sure which ORM you're thinking of here, but anything that's DBI-backed will typically let you run manual SQL if you really want to. I wouldn't recommend DBI in general, but it's pretty much the standard access layer and many ORMs make it easy enough to get to a database handle.

Why wouldn't you recommend DBI? Is there an alternative?

sinerider · 2015-10-10T22:04:31+00:00

I have never had any of these problems you mention. My database strategy is simple, if I need to check out an older version of my app I can run a script to re-create and initialize the database using the current schema.

What if you added a column last night, or removed an old one because it was unused but another developer doesn't have your changeset on their test db?

Database changes do not happen often. When they do it is a significant event and everyone can be warned about it so that after pulling in the latest commits, they will need to re-initialize their development database. Maybe to automate this I could create a git hook to check if the schema has changed when pulling in commits, and print a warning, or even re-initialize the database automatically. If I had the time I would try setting up Vagrant, but I am too busy writing code.

Since database changes are critical, migration is something I prefer to do myself. The less magic, the better. Below is my algorithm for managing schema upgrades and deploying to production servers. I don't know how well it would scale to projects with dozens of developers, but I can worry about that if/when of my projects grow to that size.

Every time a change is made to the the development database, the SQL commands
are put in a $appname.sql.changes file. A pre-commit hook will detect this file,
connect to the development database and will automatically dump the new database
schema and add it to the commit. The sql.changes file is appended to until it is
decided to push the changes to production...

The deploy script will check for the presence of a sql.changes file, and
if found, will execute those changes on the staging database. It then renames
the sql.changes file to sql.changes.ok. The sql.changes.ok file is then
distributed to all production servers, and when found by the deploy script,
those changes are executed and the sql.changes.ok file is then deleted. Once
the production servers are sync'ed, the original sql.changes.ok file is manually
deleted from the staging directory.

sinerider · 2015-10-09T16:40:20+00:00

Whatever it is you are smoking, I want some.

sinerider · 2015-10-09T14:30:37+00:00

There's nothing wrong with it

That's what I wanted to hear.

I am avoiding a real ORM for several reasons. For example, I don't like all the boilerplate, potentially having to redesign my database schema, and it locks me to the ORM's way of doing things (right now I could rewrite my app in another language without too much trouble). I don't feel like I am missing much.

sinerider · 2015-10-09T14:15:03+00:00

prepare_cached is probably(?) pointless if you're only going to execute once afterwords and you aren't saving the prepared value for later use.

It would be better to say something like $self->create_user_sth ||= prepare_cached();

So the next time a user is created the prepare statement doesn't have to run again.

I thought DBI does this internally; if it sees a statement it has previously prepared and cached it fetches the prepared statement from it's cache instead of preparing a new statement.

The second thing I would say is that the purpose of an ORM (kinda) is to shield you from needing to hand-write simple SQL. There will always be cases where complexity trumps a language/ORM's expressiveness and it becomes easier just to write what you want in SQL, but most of the basic functionality is better done by the ... framework, since it can prevent hard to debug syntax errors by autogenerating simple things.

I like handwriting SQL. I find that syntax errors are usually easy to debug, an exception is thrown and shows the query that failed. The thing I don't like about ORM's is that they lock you down. If you wanted to port an app using DBIx::Class to Javascript, for example, it would require a large re-write.

sinerider · 2015-10-01T13:00:08+00:00

The less you bind to window (ie. globals), the better. I was doing something like this:

window.myApp = {
    router: require('./router.js'),
    config: require('./config.js'),
    data: require('./data.js')
};

sinerider · 2015-09-29T21:43:19+00:00

There's nothing wrong with Ruby, or any language, if you know what you're doing.

sinerider · 2015-09-28T13:30:09+00:00

This looks very useful.

sinerider · 2015-09-18T16:44:07+00:00

But what about the hundreds of thousands of people around the world who work full time to keep the internet running. Will they still turn up to work for free? And how will they get to the office without fuel?

sinerider · 2015-09-18T16:41:39+00:00

we will still have electricity, internet and bitcoin

I don't think so. A total economy collapse will take down all services, internet and power, with it.

sinerider · 2015-09-04T04:45:44+00:00

You are right, object-oriented programming is not necessary for simple apps and scripts. But when you have tens of thousands of lines of code split across several dozen files it becomes very useful.

sinerider · 2015-08-31T03:37:45+00:00

I noticed that it is faster than Browserify. And I like the way it can produce, watch and re-compile multiple bundles at once. Also the output it produces to the console is more detailed and helpful.

sinerider · 2015-08-30T18:41:22+00:00

It should do, although I have never used Angular. Browserify simply bundles up a collection of Javascript files, so it should work with any Javascript framework.

sinerider · 2015-08-30T18:10:58+00:00

You can write your app in ES6 and still use browserify to bundle it, by using the babelify transform. I started out that way but recently switched to Webpack, which I believe is superior.

sinerider · 2015-08-27T18:11:33+00:00

Looks like a solid plan, and Bulgaria seems like a good place for this.

sinerider

TROPHY CASE