Decorated multi-threaded static methods

Decorated multi-threaded static methods

 

Advertisements

web.py and Django ORM together at-last !!!

web.py and Django ORM together at-last !!!

Django through the Firewall

Once upon a time, in a galaxy far far away… Yeah you probably heard that one before too…  Still developing a Django App behind a Firewall that has to interact with Amazon RDS and Amazon Elasticache might encounter a problem or two unless you read this post.

See also: SSH Tunnel Magic

The Problem

Developing behind a Firewall.

Cannot reach services like mailgun which can be used to send emails.

The Solution

Make Django Server communicate through a Proxy that happens to be attached to a Putty SSH Tunnel.

See also: PySocks

Adjust your Django App Startup as follows:

3-1-2013 1-58-45 PM

Your actual mileage may vary… some assembly required…  Obviously I tend to make modifications where few dare to tread but then I also get the results I want.

The Test

Ran the Django App and clicked the link to send an email via mailgun and bingo !!!  It Worked !!!

 

 

 

SSH Tunnel Magic

SSH Tunnels can be quite useful for those of us who use them to craft our own very secure yet very simple VPNs.

Consider the following diagram:

2-24-2013 10-23-46 AM

 

Laptop sitting behind a Corporate Firewall connects with an EC2 Instance via SSH forming a secure Tunnel.

EC2 Instance #1 forms an SSH Tunnel to EC2 Instance #2.

Laptop is then able to Tunnel directly to EC2 #2 thus allowing access to an RDS Cluster and a Memcache Cluster directly as though they were connected directly to the laptop.

Why do all this ?

Very simply one can more readily develop a Web App meant to run in an EC2 Instance that use RDS and Memcache hosted at Amazon when the development environment is able to use both RDS and Memcache during development.  Deployment becomes quite trivial.

The Real Deal

The real point for all this should be rather obvious… Port 22 was the only port allowed through the Firewall however Port 2222 is the port EC2 #2 uses for SSH… obviously it was not possible to use Port 2222 directly from the Laptop.  SSH Tunnel resolves this and many other problems without having to make any changes to the Firewall.

 

Cloud Security

Secure your Virtual Machines in the cloud by doing the following:

  1. Reduce your open ports to as few as possible.
  2. Do NOT allow any process serving as a TCP/IP listener to run as root.
  3. Change your SSH port from 22 to something other than 22.
    1. Change this every day if you are paranoid.
    2. Change this every hour if your are crazy paranoid.
  4. Use only Public Key Encryption for SSH access.
    1. Change your Public Keys every day if you are paranoid.
    2. Change your Public Keys every hour if you are crazy paranoid.
    3. Use only 2048 bit keys whether paranoid or not.
  5. Deny root level access for all users other than via the console and ensure the console requires physical access in a secure building.
    1. Deny root level access completely if paranoid.
  6. Encrypt your disks – this keeps those who may steal your VM Image from being able to use it.

Hackers will exploit those details you have neglected !!!

Leave too many ports open with root level access and YOU will be hacked !!!

Make things too convenient for your own use and YOU will be hacked !!!

Remain ignorant of how hackers work and YOU will be hacked !!!

Be lazy and stupid and YOU will be hacked !!!

 

 

 

Thank god for Google !!!

What in the world would any of us do without Google ?!?   Why we might have to begin thinking for ourselves were it not for Google…

Google Python Style Guide

Thank YOU Google !!!

I just hope Google someday gets around to saying things like, “…code reuse is a good thing…”.

Model View Presenter (MVP) VS Model View Controller (MVC)

As a Computer Science Professional I am here to tell you there is no real difference between MVC and MVP even though the following article seems say there is:

http://blog.vuscode.com/malovicn/archive/2007/12/18/model-view-presenter-mvp-vs-model-view-controller-mvc.aspx

Whether or not a View knows about or has contact with a Model or not is a very moot point for the following reason:

View as a means of presenting information MUST have knowledge of the Model !!!

MVP seems to say a View does not have interactions with a Model however the purpose of a View is to present data from the Model for user interaction therefore one cannot have a functional View unless it knows about the data.

MVP can claim the Presenter funnels data to the view all day long however this notion is trumped by the very simple fact that the View MUST have access to the data in order to be functional as a means of obtaining user interaction.

So let’s say in MVP the View knows nothing about the Model because it is the Presenter that knows about the data; so we make an API the View can use when it needs data from the Model.  This is exactly the same thing as allowing the View to interact with the data from the Model because Views exist to show data from Models.

No matter what we do Views and Models will always be closely related !!!

MVP is therefore nothing but a conceptualization one cannot hope to achieve because any View that does not know about its data is useless as a View.

Controllers or Presenters will ALWAYS have to know about the data from the Model because Controller/Presenter must know how to push data into the Database as well as retrieve data from the database – this is largely why the Controller/Presenter exists.

Views will ALWAYS have to know about the data because this is why the View exists; Views exist to interact with the user and users want to see the data.

Models will ALWAYS have to know about the data and provide data to the View either directly in MVC or indirectly in MVP however since Views exist to handle data from Models and Models exist to provide data to Views there is little to be gained from claiming Views and Models are not as closely related as they must be.

But again, you will always find people who think hot water is very different from cold water when all along both hot and cold water are still wet.  Likewise, MVP and MVC must do the very same work or they are useless; do too much with MVP and it becomes MVC and vice-versa just as hot water can become cold water when energy is allowed to be acted-upon my entropy.

Those who wish to market their skills will always come on the scene and make claims about their ideas when all they are really doing is showing the rest of us they are talking about the same concepts that have always existed.

Within the context of a single Application or System all Model-View-Controller triads regardless of what they are called are intimately connected to each other and CANNOT be logically separated from each other other than through some conceptualization that lacks any real substance.  Model Objects from one Application might be used by another Application with a different set of Views however this does not necessarily make the Models completely separate from either Application’s Views.  The same thing can be said about Controller/Presenter objects and Views.  Views from one Application CANNOT be easily copied to a different Application without their associated Models.

Since MVP seeks to tie Presenters to Views one makes it far more difficult to separate Views from Presenters just as Models cannot be easily separated from Views in the MVC Model – so in the end MVC has as many strengths and weaknesses as MVP even though each conceptualization tends to present what appears to be a different set of strengths and weaknesses.

MVP only seems to improve MVC… it may actually do the opposite for all anyone knows.

I am sure my views will not make me popular among those who love MVP however I believe my views to be well founded in Computer Science.

%d bloggers like this: