Argh preinstalled software which cannot be uninstalled... the worst kind.
Usually you can just uninstall crap like this from the control panel or from the Vaio Care suite, but no not this one...
Open up a command prompt and paste these instructions.
regsvr32 /u "C:\Program Files\Sony\VAIO Gate\VAIOGateDesktopShellExt.dll"
regsvr32 /u "C:\Program Files\Sony\VAIO Gate\EN-US\VAIOGateShellExt.dll"
del /F "C:\Program Files\Sony\VAIO Gate"
And viola!
Anything else I can help you with?
When I downloaded the latest drivers for Synaptics touchpad, I didn't expect it to come with Scrybe (even though the package specifically says "with Scrybe")
Well, when I saw it appear on my taskbar my immediate instinct was to kill it. What foul heathen dare trespass on my grounds!?
Shamefully, there was no uninstaller provided. Strangely enough, it was easy to kill it, which I'm not complaining about.
net stop ScrybeUpdater
sc delete ScrybeUpdater
del /F "C:\Program Files (x86)\Synaptics\Scrybe"
Obviously replacing "Program Files (x86)" with "Program Files" if you've got 32bit Windows.
Eat that bundleware!
Something that's been annoying me for a while is the lack of template tag definitions.
Today I gleamed the template code and found something that would help.
To identify between a listing page (a list of blog posts) and a detail page (a page dedicated to a particular post, where comments are shown), you need the following condition check.
<b:if cond='data:blog.pageType == "item"'>
<p>This is the post item page. Put your code here</p>
</b:if>
Now, where was I again? Oh yeah, the sign-off image.
This is definitely an issue that can slip under the radar without any explicit warnings. To get an idea of the issue at hand, imagine this scenario.
from django.db import transaction, models, connection
@transaction.commit_on_success
def safe_view(request):
# Object 1
x, is_new = SomeModel.objects.get_or_create(arg1 = '1', arg2 = '2')
x.some_custom_sql()
# Object 2
y = ImageModel(associated_object = x)
y.caption = "This should be created if the whole request is valid"
y.save()
# Abort
raise Exception("STOP! Hammertime.")
class SomeModel(models.Model):
title = models.TextField()
def some_custom_sql(self):
sql = "UPDATE %s SET fti = to_tsvector('%s') WHERE %s = %s" % (self._meta.db_table, self.title, self._meta.pk.column, self.pk)
cursor = connection.cursor()
cursor.execute(sql)
cursor.execute("COMMIT;") Because the view safe_view() is wrapped in a transaction, you would presume that any code in there will be rolled back if an exception were to occur, so an instance of SomeModel and ImageModel would not exist.
However, due to an explicit call to "COMMIT" in some_custom_sql(), the transaction is finalised by the time it returns back to safe_view().
Once the code continues, it will create an instance of ImageModel and save it to the database.
Even though the view is wrapped in commit_on_success() and an exception is raised, the changes to the database are already permenant.
EBy the time you hit the exception, it would have:
This is not ideal!
To prevent this, refrain from using "COMMIT" in raw SQL unless you know exactly what you're doing!
Instead, replace cursor.execute("COMMIT;") with transaction.commit_unless_managed(). It'll automatically detect if the database is locked in a transaction before committing the transaction.
This problem looks incredibly easy to spot when it's next to each other on the same page, but remember that the "COMMIT" lines could be anywhere in your project. Even in 3rd party modules you've downloaded.
They will silently break your transactions and leave little evidence of permanent database changes until somebody notices!
Be vigilant and you will spot out all the problems in no time!
Oh my God, twitter bootstrap is a pretty damn good styling and widget framework. Check it out!
My first issue with it however is that I couldn't find a way to change the tooltip label after it's been created.
It's easily solved, but with a rather convoluted and hidden method.
$('#target').attr('data-original-title', item.value + ' selected.').tooltip('fixTitle'); What this one line wonder does is change the title attribute, then tell it to update using the "fixTitle" call.
BOOM! HEADSHOT!
When a user uploads a file using forms.FileField, you usually want to save it in some way.
To stash the file away on disk, just use the following snippet.
from django.core.files.storage import default_storage
from django.core.files.base import ContentFile
file = request.FILES['your_file_fieldname']
path = default_storage.save('heart_of_the_swarm.txt', ContentFile(file.read())) There you have it!
Now back to more important things, like eating cheerleaders.
This was a bit of a tricky one to figure out. The reason being we store our files not in the file system but using MogileFS, which required a custom Storage wrapper.
So our model looks a little something like this.
class Product(models.Model):
# other fields
image = models.FileField(storage = MogileFSStorage(), upload_to = 'product_images') And that's completely fine if we're using the admin to manually upload image files.
However, if we wanted to programmatically save an image using code... Where do we begin?
I'm glad to say that it's actually easier than expected.
from django.core.files import File
from django.core.files.temp import NamedTemporaryFile
product = Product()
# set all your variables here
product.save()
# Save image
image_url = 'http://whatever.com/image.jpg'
img_temp = NamedTemporaryFile(delete = True)
img_temp.write(urlopen(image_url).read())
img_temp.flush()
product.image.save("image_%s" % product.pk, File(img_temp))
product.save() And that's it! There's no need to worry about storage stuff because that's handled at the model declaration level.
This code should work fine for both FileField and ImageField.
Of course, how to access the file is completely up to you and out of the scope of this post.
It'll all makes sense once someone puts it into perspective for you!
This has been bugging me for a good while. Tracked it down to the Facebook "Like" widget taking up more horizontal real-estate than it should.
If I deleted the fb-like widget, everything would go back to normal. Unfortunately, that's not proper solution...
So why is it even showing up!?
So what now?
The answer lies a few elements above. The one just above the <script> tag. There's a hidden div #fb-root.FB_UI_Hidden, which has a div and iframe nested inside it.
That iframe is injected during load time and although out of sight, it has a width of 575px causing the horizontal scrollbar to show unnecessarily.
Solution? Well first, don't use overflow; hidden on the <body> tag as suggested here. That's just silly because it disables your scrollbars altogether.
The correct method is to target CSS styling to it and restrict the width.
.FB_UI_Hidden { width: 100px !important; } That's it! Another one line wonder.
When creating the full text index search layer in Django, I had a little issue when new models were created.
Luckily, it's quite easy to create custom database types in your models.
class TSearchVectorField(models.fields.TextField):
"""
This lets Django know how to create a field with the "tsvector" type.
"""
description = "Tsearch Vector"
def db_type(self, connection):
return 'tsvector'
class TSearch(models.Model):
fti = TSearchVectorField() 
Elegant, like a flock of Seagals.
I would have thought there was some trickery or magic to this, or some sort of hidden Django function/signal to use.
But NOPE! With Python, it's a one line wonder!
# Get all subclasses for class
type.__subclasses__(Subscription) That's it! Best part is there's no special imports to do, "type" is already a built-in, so it's available anywhere at any time.
High 5's all round, fuck yeah!
