Jack @ ASP.NET

As a software engineer, I focus on .NET, especially asp.net, C#, WCF and so on, and I am also very interested in Search Engine Optimization.

Entries for the ‘Programming’ Category

logging in Django

Logging to console

1. Use Print

e.g.

def index(req):

    print “hello!”

and you will see the ‘hello!’ on your console. (or apache log if running on linux)

2. Use Python logging feature

# in settings.py

import logging

logging.basicConfig(

    level = logging.DEBUG,

    format = ‘%(asctime)s %(levelname)s %(message)s’

)

# write log

import logging

logging.debug(‘hello’)

and you can also see the ‘hello’ on your console.

 

Logging to a file

# in settings.py

import logging

logging.basicConfig(

    level = logging.DEBUG,

    format = ‘%(asctime)s %(levelname)s %(message)s’,

    filename = ‘/tmp/django.log’,

    filemode=’w’

)

# write log

import logging

logging.debug(‘hello’)

you can see your ‘hello’ in the ‘/tmp’/django.log’ file

PyDev – an Eclipse plugin for Python(Django)

PyDev is a Python IDE for Eclipse, which may be used in Python, Jython and IronPython development.

It comes with many goodies such as:

  •     Django integration
  •     Code completion
  •     Code completion with auto import
  •     Syntax highlighting
  •     Code analysis
  •     Remote debugger
  •     Tokens browser
  •     Interactive console
  •     Unittest integration
  •     Code coverage
  •     Go to definition
  •     Refactoring
  •     Mark occurrences
  •     Debugger

For Django integration

The Django integration in PyDev works through 3 main configurations:

1. The project must be marked as a Django project inside of PyDev.

2. A ‘DJANGO_MANAGE_LOCATION’ string substitution variable must point to the project-relative location of manage.py.

3. A ‘DJANGO_SETTINGS_MODULE’ string substitution variable must contain the name of the settings module in that project.

And that’s it, with those properly configured, all the Django-related actions should work (and the steps below will explain how those can be configured).

Duplicate Code

Duplicate code, sometimes referred to as clones, is a cluster of code blocks that are functionally equivalent (or nearly equivalent) spanning across two or more locations within a solution. Duplicate code is expensive to maintain because:

  1. Multiplied bugs. A bug in one clone means there’s a bug in all the copies. This can lead to a continued, repeated release of previously-fixed bugs as each copy of the bug is individually discovered by a customer and then fixed by the team.
  2. Flexibility barriers. If the copied code needs to be more flexible, changes need to be made across all the copies or ideally, the copies need to be consolidated first. Unfortunately consolidation is a high-risk, error-prone, time-consuming activity.
  3. Increased ramp-up time. Copy the code and new developers trying to get up to speed will have twice as much code to read and understand. If discovered, duplicated code tends to be harder to understand than normal code because the reader must not only understand functionality, but also understand the reason behind the duplication.

Pipeline in PowerShell

PowerShell uses a pipeline for all command entries, which feeds the results of the preceding command directly into the subsequent command. The pipeline is active even when you enter only a single command because PowerShell always automatically adds the Out-Default cmdlet at the pipeline’s end so that it always results in a two-member instruction chain.

Single command results are passed as objects. The cmdlets can filter, sort, compare, measure, expand, and restrict pipeline elements. All cmdlets accomplish this on the basis
of object properties. In the process, the pipeline distinguishes between sequential and streaming modes. In streaming mode, command results are each collected, and then passed in mass onto the next command. Which mode you use depends solely on the pipeline commands used. Output cmdlets dispose of output. If you specify none, PowerShell automatically uses Out-Host to output the results in the console. However, you could just as well send results to a file or printer.

All output cmdlets convert objects into readable text while formatting cmdlets are responsible for conversion. Normally, formatting cmdlets convert only the most important, but if requested, all objects into text. The Extended Type System (ETS) helps convert objects into text. The ETS uses internal records that specify the best way of converting a particular object type into text. If an object type isn’t in an ETS internal record, the ETS resorts to a heuristic method, which is guided by, among other things, how many properties are contained in the unknown object.

In addition to traditional output cmdlets, export cmdlets store objects either as comma-separated lists that can be opened in Excel or serialized in an XML format. Serialized objects can be comfortably converted back into objects at a later time. Because when exporting, in contrast to outputting, only plain object properties, without cosmetic formatting, are stored so that no formatting cmdlets are used.

Interactive PowerShell

The PowerShell console runs all kinds of commands interactively: you enter a command, and the console will more or less immediately return the results. If you enter a command and execute it by pressing (Enter), PowerShell looks for the command in this order:

  • Alias: It will first look to see if your command corresponds to an alias. If it does, the command will be executed that the alias designates. You can "overwrite" any other command with an alias by using the cmdlet Set-Alias because aliases have highest priority.
  • Function: If no alias could be found, PowerShell looks next for a function, which resembles an alias, but can consist of many PowerShell instructions. You can wrap commands, including frequently used arguments, in functions.
  • Cmdlet: If it’s not possible to find a function, PowerShell looks for cmdlets, which are internal PowerShell commands that conform to strict naming rules and whose names always consist of a verb and a noun.
  • Application: PowerShell looks first for a cmdlet, and if it can’t find any, it then searches for external commands in the subdirectories specified in the Path environment variables. If you’d like to use a command at some other location, then you must specify a relative or absolute path name.
  • Script: If PowerShell can’t find any external commands, it looks next for a script with the file extension ".ps1". However, scripts are executed only when restrictions of the ExecutionPolicy are eased, allowing PowerShell scripts to be run.
  • Files: If no PowerShell scripts are found, PowerShell keeps looking for other files. PowerShell
    reports an error if your command doesn’t match any files.

Versioning and optional parameters

The restrictions on default values for optional parameters may remind you of the restrictions on const fields or attribute values, and they behave very similarly. In both cases, when the compiler references the value, it copies it directly into the output. The generated IL acts exactly as if your original source code had contained the default value. This means if you ever change the default value without recompiling everything that references it, the old callers will still be using the old default value. To make this concrete, imagine this set of steps:

  1. Create a class library  with a class like this:
    public class MyDemo
    {
    	public static void PrintValue(int value = 10)
    	{
    		System.Console.WriteLine(value);
    	}
    }
  2. Create a console application (Application.exe) that references the class library:
    public class Program
    {
    	static void Main()
    	{
    		MyDemo.PrintValue();
    	}
    }
  3. Run the application—it’ll print 10, predictably.
  4. Change the declaration of PrintValue as follows, then recompile just the class library:
    public static void PrintValue(int value = 20)
  5. Rerun the application—it’ll still print 10. The value has been compiled directly into the executable.
  6. Recompile the application and rerun it—this time it’ll print 20.

This versioning issue can cause bugs that are hard to track down, because all the code looks correct. Essentially, you’re restricted to using genuine constants that should never change as default values for optional parameters. There’s one benefit of this setup: it gives the caller a guarantee that the value it knew about at compile-time is the one that’ll be used. Developers may feel more comfortable with that than with a dynamically computed value, or one that depends on the version of the library used at execution time.

Of course, this also means you can’t use any values that can’t be expressed as constants anyway—you can’t create a method with a default value of “the current time,” for example.