Put the knife down and take a green herb, dude. (c) Ruffin Bailey 2001-2021

Windows Phone Mango Local Database(SQL CE): Introduction | GeekChamp:

LINQ is used to query data, T-SQL queries are not supported

I've already complained about the lack of DataTables on Windows Phone 8. That still boggles my mind. Why not make code supra easy to port over to Windows Phone? When it's easier to reuse my C# code on iOS and Android ($300 a piece and I'm ready to go) than on Windows' own native platforms, something's wrong.

And then I see alternatives like the one above. Admittedly, that article is pretty old, and mentions WP 7.1, but the use of LINQ exclusively instead of supporting SQL I don't quite understand.

I mean, I know ORMs are the [conventional] way to do things now. But even they, at least on your standard server-side or desktop stacks, usually end up translating object relations to SQL. I haven't seen a huge practical advantage for ORMs on the systems I've worked on. I keep hearing that it makes swapping database engines easier, but I'll keep ignoring that until someone actually replaces SQL Server with PostgreSQL -- and it's painless enough to make up for carrying, eg, NHibernate around for years.

It's really not that all difficult to custom hydrate objects with SQL results, and when it is, you often run into similar trouble trying to shoehorn your data into your ORM via AutoMapper or something similar anyhow. And in most of those complex cases, it would be much easier for those who know how to do just a little bit more than spell "SQL" to have scripted up a sproc to do what the ORM is doing -- and to have that logic processed on the database server, where it's supposed to be happening anyhow. I'm almost speechless at this point. I mean, you're paying how much to have software (the rdbms, to be clear) that's designed to handle complex relationships quickly and efficiently? Quickly processing complex relationships in your data is your database server's job. Why do we push that to middleware?

Sorry. I'll try not to step so close to that soapbox again, as it's horribly difficult not to step up off of Britannia and start spewing.

Anyhow, this convention of object-ing your way to data rather than SQLing your way has gone from convention to serious technical block with Windows Phone. I don't see how Xamarin abstracts twice -- once from whatever XCode is pushing out to Objective-C or Eclipse to a Java VM, and then again to C# -- on a platform that dips as low, performance-wise, as Android can, and still gives a more fully fledged development platform than Windows Phone. I mean, heck, VB.NET was a non-trivial attempt to pull VB6 programmers onto the web and OO programming with the least amount of head rethreading possible, and it happened because having Microsoft stack developers on .NET was crucial to that platform's success. Why the huge investment during the move to .NET but not Windows Phone and "Metro"/Windows App Store? One platform has been adopted very quickly. I realize the WP numbers are low, but don't you think some developer love would push adoption in business pretty danged quickly too? It's all about the barriers to entry, stupid.

Guess this stayed a pretty ranty post. Sorry.

Anyhow, so my answer so far, since my mobile apps are just for fun, is to create a DataTable shim for Windows Phone, DataTableWP8, that shims just enough to let me use my buggy SQL database, now called SqlDbSharp (because naming is difficult ;^D), on WP8 without rewriting anything. So far, it's still fun to do, and I've been playing with Visual Studio on my Lenovo laptop as much or more as Xamarin Studio on my new iMac in my free time this week.

Labels: c#, DataTableWP8, mono, SqlDbSharp, windows phone, xamarin

So my relative dislike of any mergetool that I've tried (list below) has me slowly coding my way to one of my own. I think it's a doable task, now that I've nearly got the [exceptionally simplistic] diff engine close to done. A good mergetool seems to be mostly about the UI, honestly. Can I tell what I'm doing, what's in the current file I'm about to check back in, and the source of each of those edits? Can I tell that I've handled each conflict?

I've got a number of ideas of what's really needed -- saves of past unconflict sessions, quick summations of how much of each file (local, remote, base) you've put into the unconflicted file, the ability to look at the file's history beyond local/remote/base into other branches and farther back in history, etc -- and that's largely GUI driven. I might need a middleware tier for interfacing with git, but that's about it for the faceless code.

The UI, on the other hand, is going to be a bear.

Anyhow, doing this in Mono so that it's crossplatform is both exceptionally cool and horribly painful. Cool in that the faceless C# code really does work great no matter where I run it. Cool in that my code, all written in MonoDevelop on OS X, "just runs" when I opened it in Visual Studio 2010 for fun today. I'm inserting a screenshot, just because it's crazy cool how easily the Mac developed code opens in Microsoft-land.

(Note that it's obviously not close to done yet; still just playing with the diff engine and learning how to do everything in Windows.Forms programmatically -- no RAD designers in MonoDevelop for Windows.Forms. Gtk#, sure. Windows.Forms, no.)

The pain I've documented largely already. You'll notice no highlighting in that screenshot; just colored text. That's b/c highlighting doesn't work on Mono's Windows.Forms for Mac. Nor do ToolStrips. Nor does every menu accelerator. It's a mess.

Just for fun, I'll include a Mac screenshot here... I don't have it handy, so I'll include the one from sourceforge for now. For some bizarre reason, their system added a horrible black border around the image to make it look like it's on an old TV. Go figure.

Which means I'll eventually need to use MonoMac -- a bridge between Mono code and native UIs designed in XCode -- to finish up a quality unconflict for OS X. And since it appears so much of a good mergetool is UI, that means a lot of repeated logic.

Oh well. For now, I'll just use the ugly lowest common denominator of Windows.Forms on OS X, then fork like mad when I get to a good stopping point.

Final thought for now: Writing the diff engine is actually pretty neat. Makes you appreciate what mergetools and diff functions are really doing. You'll notice the "-1" out in front of some lines. That means those lines "didn't change", relatively speaking. That's the wrong way to do a diff. Initially I had way too much of a file-centric approach to diffs, and not diff-centric enough. Working on that. And to do it right, you have to make at least two passes through the code to work out when what's moved has changed order or not.

mergetools I've tried and not really liked:

WinMerge: No three-way merge. Leaves crappy files to clean up. Not updated in a long time, and the rewrite seems dead.
p4merge: Great ideas, poor implementation. Love the icons, but I can't always see them. Also hard, with current highlight scheme, to see what I've inserted and what's an option for inserting. No hard confirm on saves.
FileMerge: Two-way merge, poorly done, at least when SourceTree calls it. Works fine (aka, "reliable"), I guess, but featureless.
vimdiff: Good, but though I love VIm in general, I'm newbie enough to merging files to want to to use a mouse and have more helpful UI cues than just highlighted colors over what amount to tiled xwindows.
kdiff3: For some reason, I can't get this to integrate correctly. Using something as a mergetool should be easy. Few are. I don't think this is always saving when and where I think it's saving (same deal with WinMerge and p4merge at times), and often (likely b/c of a flaw in my script, I guess) isn't opening when it's called from cmd line or the git GUI I'm using. Also a little bit of a stodgy interface.

Labels: git, mono, monomac, unconflict

title: Put the knife down and take a green herb, dude.	descrip: One feller's views on the state of everyday computer science & its application (and now, OTHER STUFF) who isn't rich enough to shell out for www.myfreakinfirst-andlast-name.com Using 89% of the same design the blog had in 2001.
FOR ENTERTAINMENT PURPOSES ONLY!!! Back-up your data and, when you bike, always wear white. As an Amazon Associate, I earn from qualifying purchases. Affiliate links in green.
x MarkUpDown is the best Markdown editor for professionals on Windows 10. It includes two-pane live preview, in-app uploads to imgur for image hosting, and MultiMarkdown table support. Features you won't find anywhere else include... MarkUpDown Multiline Table & Bootstrap Grid support. Beautiful Easy Actions that keep the Markdown flowing. HTML paste to paste HTML source into your documents. You've wasted more than $15 of your time looking for a great Markdown editor. Stop looking. MarkUpDown is the app you're looking for. Learn more or head over to the 'Store now!

Saturday, January 25, 2014
Why is WP8 contra SQL and conventional Data objects? Windows Phone Mango Local Database(SQL CE): Introduction \| GeekChamp: LINQ is used to query data, T-SQL queries are not supported I've already complained about the lack of DataTables on Windows Phone 8. That still boggles my mind. Why not make code supra easy to port over to Windows Phone? When it's easier to reuse my C# code on iOS and Android ($300 a piece and I'm ready to go) than on Windows' own native platforms, something's wrong. And then I see alternatives like the one above. Admittedly, that article is pretty old, and mentions WP 7.1, but the use of LINQ exclusively instead of supporting SQL I don't quite understand. I mean, I know ORMs are the [conventional] way to do things now. But even they, at least on your standard server-side or desktop stacks, usually end up translating object relations to SQL. I haven't seen a huge practical advantage for ORMs on the systems I've worked on. I keep hearing that it makes swapping database engines easier, but I'll keep ignoring that until someone actually replaces SQL Server with PostgreSQL -- and it's painless enough to make up for carrying, eg, NHibernate around for years. It's really not that all difficult to custom hydrate objects with SQL results, and when it is, you often run into similar trouble trying to shoehorn your data into your ORM via AutoMapper or something similar anyhow. And in most of those complex cases, it would be much easier for those who know how to do just a little bit more than spell "SQL" to have scripted up a sproc to do what the ORM is doing -- and to have that logic processed on the database server, where it's supposed to be happening anyhow. I'm almost speechless at this point. I mean, you're paying how much to have software (the rdbms, to be clear) that's designed to handle complex relationships quickly and efficiently? Quickly processing complex relationships in your data is your database server's job. Why do we push that to middleware? Sorry. I'll try not to step so close to that soapbox again, as it's horribly difficult not to step up off of Britannia and start spewing. Anyhow, this convention of object-ing your way to data rather than SQLing your way has gone from convention to serious technical block with Windows Phone. I don't see how Xamarin abstracts twice -- once from whatever XCode is pushing out to Objective-C or Eclipse to a Java VM, and then again to C# -- on a platform that dips as low, performance-wise, as Android can, and still gives a more fully fledged development platform than Windows Phone. I mean, heck, VB.NET was a non-trivial attempt to pull VB6 programmers onto the web and OO programming with the least amount of head rethreading possible, and it happened because having Microsoft stack developers on .NET was crucial to that platform's success. Why the huge investment during the move to .NET but not Windows Phone and "Metro"/Windows App Store? One platform has been adopted very quickly. I realize the WP numbers are low, but don't you think some developer love would push adoption in business pretty danged quickly too? It's all about the barriers to entry, stupid. Guess this stayed a pretty ranty post. Sorry. Anyhow, so my answer so far, since my mobile apps are just for fun, is to create a DataTable shim for Windows Phone, DataTableWP8, that shims just enough to let me use my buggy SQL database, now called SqlDbSharp (because naming is difficult ;^D), on WP8 without rewriting anything. So far, it's still fun to do, and I've been playing with Visual Studio on my Lenovo laptop as much or more as Xamarin Studio on my new iMac in my free time this week. Labels: c#, DataTableWP8, mono, SqlDbSharp, windows phone, xamarin posted by ruffin at 1/25/2014 02:37:00 PM

Tuesday, April 16, 2013
Xamarin's [unexpected?] sponsors I can't tell how I feel about Microsoft's love of Mono. In a sense, it's an obvious fit. It could represent Microsoft wanting to move beyond the OS into more popular, crossplatform [, and mobile] spaces by piggybacking on Mono's work with C#. I can't say I'm against Microsoft's best (and Visual Studio has some of their best, I feel relatively confident) working on Mono! At the same time, Mono initially felt a little subversive. Less so now. We're not writing Windows Forms apps on Mac anymore. Strange the bedfellows success creates. (Brought to you by Yoda, apparently.) Labels: microsoft, mono posted by ruffin at 4/16/2013 09:39:00 AM

Saturday, November 03, 2012
Building Banshee on OS X Left Banshee building overnight, and woke up to some sort of handshake error. git clone "git@gitorious.org:~dynalon/banshee-community-extensions/banshee-community-extensions-macosx.git" "banshee-community-extensions-master.git" Cloning into banshee-community-extensions-master.git... Permission denied (publickey). fatal: The remote end hung up unexpectedly I did a little Googling, but am still not real sure what happens next. SSH with Keys HOWTO: SSH Keys with a passphrase: 5. SSH Keys with a passphrase Well that that was not too bad was it? But isn't this a bit insecure, anyone who where to gain access to my console would be able to log in to remote systems using your keys. Or what if I lost my key, the finder would be able to access every system on which I installed my public key. Here's some info on setting something simliar up for a project called Chaw. Guess I'm off to the dev list. Labels: banshee, mono, os x posted by ruffin at 11/03/2012 02:41:00 PM

Thursday, September 20, 2012
unconflict and the Mono project So my relative dislike of any mergetool that I've tried (list below) has me slowly coding my way to one of my own. I think it's a doable task, now that I've nearly got the [exceptionally simplistic] diff engine close to done. A good mergetool seems to be mostly about the UI, honestly. Can I tell what I'm doing, what's in the current file I'm about to check back in, and the source of each of those edits? Can I tell that I've handled each conflict? I've got a number of ideas of what's really needed -- saves of past unconflict sessions, quick summations of how much of each file (local, remote, base) you've put into the unconflicted file, the ability to look at the file's history beyond local/remote/base into other branches and farther back in history, etc -- and that's largely GUI driven. I might need a middleware tier for interfacing with git, but that's about it for the faceless code. The UI, on the other hand, is going to be a bear. Anyhow, doing this in Mono so that it's crossplatform is both exceptionally cool and horribly painful. Cool in that the faceless C# code really does work great no matter where I run it. Cool in that my code, all written in MonoDevelop on OS X, "just runs" when I opened it in Visual Studio 2010 for fun today. I'm inserting a screenshot, just because it's crazy cool how easily the Mac developed code opens in Microsoft-land. (Note that it's obviously not close to done yet; still just playing with the diff engine and learning how to do everything in Windows.Forms programmatically -- no RAD designers in MonoDevelop for Windows.Forms. Gtk#, sure. Windows.Forms, no.) The pain I've documented largely already. You'll notice no highlighting in that screenshot; just colored text. That's b/c highlighting doesn't work on Mono's Windows.Forms for Mac. Nor do ToolStrips. Nor does every menu accelerator. It's a mess. Just for fun, I'll include a Mac screenshot here... I don't have it handy, so I'll include the one from sourceforge for now. For some bizarre reason, their system added a horrible black border around the image to make it look like it's on an old TV. Go figure. Which means I'll eventually need to use MonoMac -- a bridge between Mono code and native UIs designed in XCode -- to finish up a quality unconflict for OS X. And since it appears so much of a good mergetool is UI, that means a lot of repeated logic. Oh well. For now, I'll just use the ugly lowest common denominator of Windows.Forms on OS X, then fork like mad when I get to a good stopping point. Final thought for now: Writing the diff engine is actually pretty neat. Makes you appreciate what mergetools and diff functions are really doing. You'll notice the "-1" out in front of some lines. That means those lines "didn't change", relatively speaking. That's the wrong way to do a diff. Initially I had way too much of a file-centric approach to diffs, and not diff-centric enough. Working on that. And to do it right, you have to make at least two passes through the code to work out when what's moved has changed order or not. mergetools I've tried and not really liked: WinMerge: No three-way merge. Leaves crappy files to clean up. Not updated in a long time, and the rewrite seems dead. p4merge: Great ideas, poor implementation. Love the icons, but I can't always see them. Also hard, with current highlight scheme, to see what I've inserted and what's an option for inserting. No hard confirm on saves. FileMerge: Two-way merge, poorly done, at least when SourceTree calls it. Works fine (aka, "reliable"), I guess, but featureless. vimdiff: Good, but though I love VIm in general, I'm newbie enough to merging files to want to to use a mouse and have more helpful UI cues than just highlighted colors over what amount to tiled xwindows. kdiff3: For some reason, I can't get this to integrate correctly. Using something as a mergetool should be easy. Few are. I don't think this is always saving when and where I think it's saving (same deal with WinMerge and p4merge at times), and often (likely b/c of a flaw in my script, I guess) isn't opening when it's called from cmd line or the git GUI I'm using. Also a little bit of a stodgy interface. Labels: git, mono, monomac, unconflict posted by ruffin at 9/20/2012 01:25:00 PM

Friday, September 07, 2012
TweetStation -- sample MonoTouch app TweetStation has all the important features for a twitter client: Chicken noises Sampled chicken noises are played back on refresh to ensure that you do not take Twitter too seriously Music Playback Music playback during message composition will encourage you to write the best possible tweet you can, to create witty and insightful remarks instead of yet another "me too" comment. More importantly, it's a sample app for using MonoTouch and building for iOS, and has an MIT X11 license. It looks like MonoTouch for iOS is much more fully supported (and by that, I certainly include sample code) than Mono on the Mac in general, which, of course, makes sense. Mobile's where it's at right now, and there are more C# programmers trying to code iOS apps than Mac OS X apps, I'd imagine. Unfortunately, all I've got right now is an iPhone 3G, and though TweetStation supports iOS 4, it requires a 3GS. Not sure why. Still, free code that does cool stuff. That's good. Labels: ios, mono, monotouch posted by ruffin at 9/07/2012 10:31:00 AM

Saturday, September 01, 2012
[Mono-bugs] [Bug 75996][Maj] New - menuitem event not triggered by Shortcut [Mono-bugs] [Bug 75996][Maj] New - menuitem event not triggered by Shortcut: [Mono-bugs] [Bug 75996][Maj] New - menuitem event not triggered by Shortcut bugzilla-daemon at bugzilla.ximian.com bugzilla-daemon at bugzilla.ximian.com Tue Sep 6 05:52:00 EDT 2005 /sigh I don't think that's been fixed. You know how, when you initially write an app, that you pretty go in and create a good 80% of what it's supposed to look like, it finally all works together, and for at least three minutes you feel like you can rest and call it done? That's where Mono's Windows.Forms support is. It's a great, horrendously impressive beta. Tons of stuff is there, and I can use straight C# to get it all to work, no silly workarounds. But then, that last 20% is obviously lacking. I can't get SelectionBackColor on RichTextBoxes. There's potentially no working Shortcuts on MenuItems. And the Mono IRC channels says Windows.Forms is dead. I guess if I was bright enough I could fix it myself, but I don't believe the place I need to fix (some drawing lib) is even written in C#. I'm really impressed the community got this far, but they didn't quite make the Mozilla turning point before the steam disappeared. It's a "write once, rewrite your GUI everywhere" situation. I guess that's okay, but it makes me wonder how much time to sink into writing the Windows.Forms app before I make sure I understand XCode's Interface Builder. In other news, Blogger is finally starting to get backwards compatibility right. The old-style BlogThis! bookmark now opens a window that, I think, is starting to get blockquote closer to right (still borked, though), and also expands from its old size to one large enough to see the whole window now. Saves me the trouble of editing the old bookmark's javascript, which I'm embarrassed to say I still haven't. I just resized the window each time I got the new interface. Labels: c#, mono, monomac, windows.forms, xcode posted by ruffin at 9/01/2012 09:53:00 AM

Thursday, May 31, 2012
Using Interface Builder in Xcode 4 for Mono dev To look at later to help with using MonoDevelop to make Mac apps: Transitioning from Xcode 3 to Xcode 4 - Xamarin: Introduction to Interface Builder v4.0 Although Interface Builder is now integrated into Xcode, it’s still largely the same, with the exception of how Outlets and Actions are now created and wired up. Specifically, it gives you the ability to create an Outlet or an Action and wire it up to a control all in one step. If you believe what you're told, though the above link is for MonoTouch, MonoMac is similar. Labels: mono, monomac, noteToSelf, xcode posted by ruffin at 5/31/2012 11:56:00 AM

Monday, April 23, 2012
Mono hates that I'm using SQLite. There's no other explanation Bug 380252 – Mono.Data.SQLite crashes on call to SqliteDataAdapter.Fill(DataTable table) with simple SELECT: It might be useful to fix the DataTable Load & Fill methods so that sqlite3_column_origin_name() is avoided; the above email suggests: ---------------------------------- I see this issue was opened AGES AGO!!! My word guys lets fix/improve this shall we? Save the developers of the world lots of heartache... You think? Man, what a pain. Apparently all the binaries for SQLite on OS X, including the preinstalled one, bork on when you call the function `sqlite3_column_origin_name`. Luckily that's only used for stuff like, well, loading freaking DataTables. So I have to recompile SQLite to get it to work and, if I release an app using it into the wild on OS X, have to get schomes to update theirs too, which is insane. What a pain. This is why I thought I'd probably end up using C#-SQLite anyhow. Then I can include a dll that's all in C# or even embed the db in the code of my project. But what a pain when that's the easiest solution. Labels: mono, sqlite posted by ruffin at 4/23/2012 11:27:00 PM

Monday, November 14, 2011
Windows.Forms with MonoDevelop MonoDevelop WinForms? - Ubuntu Forums: Re: MonoDevelop WinForms? WinForms is the System.Windows.Forms namespace. MonoDevelop has no integrated support for designing GUIs with WinForms - instead, it has an integrated editor for GTK# GUIs. You can hand-write WinForms GUIs if you want to, though Welp, that kinda stinks. I actually ordered a horrendously inexpensive, likely wholly underpowered laptop so that I could program ASP.NET on the go (well, and to have an inexpensive copy of Windows 7 handy), and I think MonoDevelop on OS X might make me think I was an idiot for doing that for ASP.NET, but now not so much for when I want to run Windows applications. (A laptop just for Windows? RLY? I seriously considered the MacBook Air and $130 for Windows 7, but I couldn't justify the extra price. And there are times I've got to get out of the home office and run to Starbucks to keep programming, so mobility is relatively important. And, finally, I had Boot Camp on my MacBook, which doubles as my primary OS X box, before, but it wasn't particularly wieldy. I often like to boot into OS X, and being a hard reboot away was simply too far. Another laptop "needed". There's just nothing good under $400. We'll see if that AMD E-450 is any good, though CPU Benchmarks tells me probably not (compare to my Core 2 Duo and Athlon X4. Ouch.)) That said, the Windows.Forms project does run with MonoDevelop/Mono without any tinkering, which is quite impressive. Obviously GTK look and feel, but it runs! Much more robust/mature than the last time I fooled around with this, iirc. Labels: asp.net, mono posted by ruffin at 11/14/2011 11:33:00 AM

<< Older \| Newer >>