vineri, 5 decembrie 2008

Thoughts on Software Security

Here's something that grinds my gears:
You still use bla bla bla Internet Navigator v13.2.256.2?!  Don't you know that it's full of security holes? You should usee YYY Firedog 2012 because it's secure and hip, and soon everybody will be using it!
From my experience there are no perfect software programs, from the security perspective. The only thing that matters is the number of exploited security holes. And that number tends to be directly proportional to the popularity|number of users and number of functionalities of the software application.

Or worse. My theory is that the users of public software applications (meaning software meant for the masses, not for X company's HR department), with small user bases, tend to be more technically savvy. As the number of users grows, due to the increassing popularity of that software, the average naivety level tends to go up. This is the first step when things start to go bad, because the easiest security exploits rely on user ignorance.

The second step occurs when the application suffers a surge of new functionalities. This usually happens when it starts supporting some form of plugins or automation, because this greatly increasese the area exposed by that application to the world: longer borders=>more border patrols are needed.

So there is no real security comparison between two software applications, unless they have comparable user bases, have been available for the same period of time and support roughly the same major functions.

My conclusion is this: educate the user! Software doesn't need to be foolproof. Time spent on dumbing down the user interface (and I don't reffer here only to the GUI, but the whole end user experince) can be better employed on improving its functionalities.

Help the user make informed decisions. Even if this means saying "Pushing this button exposes you to the following risks: money loss, health loss, pride loss, etc.". Software applications should not follow the marketing propaganda of consumerism. In a medium where information is a de facto currency, there are better ways to advocate the use of your software. Make a commitment to inform the users what are the strong and week points of your application, when it can and when it shouldn't be used.

Stumble Upon Toolbar

marți, 2 decembrie 2008

Thoughts on Programming Languages

1. Use declarative code for the UI (XAML, HTML)
2. OO code for infrastructure (data access, etc...)
3. Functional programming for logic implementation and data manipulation
4. Python has one of the nicest syntaxes of all programming languages
5. F# could have gotten a better syntax, even if it had broke OCAML compatibility.
6. Identation for code block delimitation rocks! I wish C# would have something like that... that might be an interesting idea: a precompiler for C# that just wraps indented blocks in curly braces.

Stumble Upon Toolbar

vineri, 28 noiembrie 2008

Running Linux Apps Seamlessly Insinde Windows for 100EUROS or Less

  1. Get a license and install windows (XP/2003/Vista): blah, blah, blah, next, next, finish ... ~100E for Vista Home Premium
  2. Download & install Virtual Box: blah, blah, blah, next, next, finish ... 0E
  3. Download & install Ubuntu (latest): blah, blah, blah, next, next, finish ... 0E
  4. Press <Host key> + L ... priceless

Tada!

PS: this post was written with Google Docs on Firefox running on Ubuntu linux running on Microsoft Windows 2003.
PPS: only one operating system was restarted during the creation of this post.
Stumble Upon Toolbar

miercuri, 19 noiembrie 2008

sâmbătă, 18 octombrie 2008

Python can do:

Connect to an MS SQL database with integrated security (sample from a TurboGears aplication, using SQL Alchemy + Elixir + pyodbc):
sqlalchemy.dburi="mssql://<server name|named instance>/<database name>?sspi=true"

Next step: run TurboGears behind IIS in order to use Integrated Windows Security.
Even further: investigate if IronPython fits somewhere.

Stumble Upon Toolbar

For all our real problems are technical...

...not social, financial, political or religious:

The Zeitgeist Movement
The Venus Project
Stumble Upon Toolbar

vineri, 15 august 2008

Internet Censorship

I thought that the Internet’s purpose was breaking communication barriers:

cens

I’ve seen this situation becoming more and more common. What’s interesting is that it’s not a subtle limitation. They could have made all the links going to the limited content not available to people outside the USA. Hmm…

Update: http://timheuer.com/blog/archive/2008/08/13/nbc-olympics-behind-the-scenes.aspx


Stumble Upon Toolbar

joi, 14 august 2008

Punitive Software Development

The current project manager I’m working with, answers to all my whinnying about things that I don’t like in the current project with “M, you’re always complaining about the project and what a torture it is to work on it. You should take my example: I’ve been working on crappy software projects for the last 1134 years and I’ve never complained!”.

To which I respond “Yeah you’re kind of right, but I want my life expectancy to be greater than 50, and I don’t find premature gray hair sexy”. Of  course, I don’t say it out loud.

What did I learn from my experience with software projects:

- software projects are always short on time

- software projects must build upon and fix older, incomplete-or-completely-failed, software projects

- there aren’t enough good developers around

- developers have to completely rely on business analysts for the communication with the client

- business analysts will always be more focused on gathering request from the client, rather than trying to find solutions for their problems with the tools that the developers can provide

- the test team will be treated as if they are from Bangladesh even if they work in an office next to yours

- agile techniques are just for showing off: “Yeah, we have a two week release period for each of our builds, and we hold daily scurm meetings, and we are so agile and so extreme that I just can’t stop looking at myself in a mirror”. Yeah you dumb agile f#*k. Just a little more agile and you could lick you own balls. You think you’re agile, but you still plan a project into requirements gathering, development and implementation. Really agile, no waterfall in here. If you wouldn’t have realized that regular testing ensures that your piece of crap software is less shitty (this is the original test driven development: give the test team something that barely resembles a software product and hope they will guide you towards an acceptable application), you’d still be doing testing at the end of the development phase.

All of this must change…


Stumble Upon Toolbar

vineri, 1 august 2008

Code Generation Is Bad, M’kay?

Code generation: problem solver.
Composition, abstraction, design patterns, a walk in the park thinking of a better solution: constructive techniques.

It often tempts me to use code generation when I’m facing a problem that requires a lot of code to be written in order to solve each of it’s instances (ex: classes in the data access layer). It is the case when I’ve already used all the tools in my (small) development arsenal, and it seems I can no longer simplify and reduce the code that needs to be written by the clients of the solution. The clients being, in most cases, myself.

And the most annoying thing is that I feel there is still too much repetitive code or logic, and there must be a better way around it. But the programming language doesn’t want to help me anymore, and I can’t think of any other solution. And I try to scribble other designs, and when I think I’m onto something, and try to translate the new solution into code, there is always a catch, some missing feature of the framework library, or of the language itself, or a glitch in my logic.

And there’s the Code Generator behind me, grinning, telling me: “You know you can’t avoid me…”. But I keep on trying: “Go away, leave me alone, there must be a better solution to all this crap (that I’m mostly to blame for)!”. And he goes: “Don’t ignore me, I might be your best friend at the moment.” - “But I hate you! You are possessive, you give my code inertia, and I suffer headaches when I try to make even the smallest change.” - “Hmm, that’s an oxymoron: the best friend you hate the most. C’mon, see the bright side, your code will barely change. It will look as young as when you first wrote it, even after years of use and abuse. It will become immortal :).”

Finally I give up and I try to make up for the compromise I’m committing: “At least I will generate very beautiful code, with all the comments it needs and exception handling and bells and whistles. And there will be extension points, so I will be able to add more features to the definition, like automatic validation-based-on-some-obscure-rules-that-I-will-come–up-with…”. And I feel sad…

Well, I can’t be sad about my work. I’m still a programmer because I like programming, and I expect that software development should bring me joy and fulfillment, not frustration and sorrow. That’s the moment I start to think that if my system was built the right way, every feature should be replaceable. I don’t have to bang my head into finding a perfect solution for a functionality, that will probably be replaced in the future.

Ok, so what I really need to take care of is that the generated code is isolated enough so other parts of the system don’t have direct dependency on it, but rather on a contract the generated code implements. Maybe a smarter person will find a solution for my problem, and they usually do. At that time I’ll be able to end my unpleasant relation with the code generator, and look behind and smile.

Resources

http://c2.com/cgi/wiki?CodeGenerationIsaDesignSmell


Stumble Upon Toolbar

miercuri, 23 iulie 2008

The Evils of Shared Check Out

I won’t discuss the obvious what-do-you-do-when-somebody-else-checked-in-before-you-and-now-you’ve-ended-up-resolving-the-conflicts. I think there are more subtle motives why the version control shared check out has negative impact on modern software development.

I believe that the shared check out feature of most source control system (svn, cvs, tfs) originated in a time when developers worked on huge code files, when solving one bug meant making adjustments in more than one of these monstrosities at the same moment. In a time of stone age development tools, when modern programming concepts like OOP and FP were in still in the realm of academia and of obscure languages.

The tools and languages evolved, but the way they were used had its own inertia, based on human habit and familiarity with a way of “doing things”. Forget about one class - one concern, some people are still struggling with one function – one concern.

The conclusion is that if you are aware of a couple of development techniques, there will be no need for shared check out. One class should be modified for only one reason, so two people don’t have to edit it at the same time.

Of course there are counter examples. I already hear people shouting “configuration files”, “generated code files” etc. Those are exceptions and at the same time, they are not. If you’re willing to break the structure into small, manageable parts, you’ll find a solution for them. And if you really need to store many things into one file, be sure to set rules for how people should edit it, so they know how to not get into trouble. This is a similar problem to using only pure functional programming. FP is great, but you’ll need to modify state sometime: make sure you’re doing it in a standard, isolated way, so when a problem arises you’ll know what you’re dealing with.


Stumble Upon Toolbar

marți, 22 iulie 2008

Why You Should Write Your Own O/R Mapper ... Or At Least Try

Because you will not use it. But in the process you'll probably learn a lot of things about what a data access layer is. And more important, you'll be able to judge the existing O/R mappers and chose the one that fits most of your needs.

The down side is that the period of time before you choose to "upgrade" to an already existing solution will seem a waste, and all the code you've written must be thrown away. That won't be an issue if you keep in mind that things are replaceable and if you build a loosely coupled designed so components, like the data access layer, can be replaced, almost, effortless.

This pattern applies to other general "patterns", like dependency injection containers. Hands on experience with their "entrails" should give you a better understanding of how they work, and a better appreciation of the ones that are already available. And chances are you've already tried to build something similar but never knew exactly what you wanted, or what the big picture of the solution is.
Stumble Upon Toolbar

vineri, 18 iulie 2008

Nice Design Example for a Simple Data Access Layer

If you are in the process of implementing a small data centric application, you'll probably need to write some data access code. I've recently stumbled upon Los Techies, which is a wonderful resource for good programming practices. I especially enjoyed Jimmy Bogard's series on the problem of separation of concerns.

The series is centered towards refactoring an existing solution to a better design, employing well known patterns and practices. But the interesting part is that at the end the result is a nice blue print for a general data access layer based on Linq. And a really good start point if you're trying to build one.

Below are links for the six parts of the series:
Separation of Concerns - how not to do it
Separation of Concerns by example: Part 1
Separation of Concerns by example: Part 2
Separation of Concerns by example: Part 3
Separation of Concerns by example: Part 4
Separation of Concerns by example: Part 5
Stumble Upon Toolbar

joi, 17 iulie 2008

Linq to SQL Server CE and uniqueidentifier columns

There will be a couple of issues if you you try to use linq to sql with a SQL Server CE database. First of all the VS2008 designer doesn't allow adding tables from this type of database. The solution is to use the SqlMetal command line tool in order to generate the dbml or the code file (see here).

The second issue is that uniqueidentifier columns with the rowguid property will not work. More precisely, they will not autogenerate a value upon inserting a new row. Setting the column property to IsDbGenerated in the dbml mapping file is even worst: it will crash the insert operation. There is a workaround for this problem: in the partial class of the respective table entity, create the partial method "OnCreate" and manually set a new Guid for the new record:

partial void OnCreated()
{
    if (ID == Guid.Empty) ID = Guid.NewGuid();
}
Stumble Upon Toolbar