[Chicago] Communicating across layers in a webapp
Randy Baxley
randy7771026 at gmail.com
Sun Feb 1 23:21:13 CET 2015
You know me too well.
Just tell me that something will not work for me and I have to spend eons
proving that it could if I could just suspend time and space long enough.
Here is the latest thing I have been distracted from while the fun of Ng's
machine learning class is my favorite toy of the moment. It does have the
side bennie of my reading a lot of Pycharm help files late at night as I
try to figure out hou dependencies work.
The amazing thing to me is that we did all the ML things in the 80s with
what at the time seemed very simple tools in DOS and C. Of course we did
not have fancy UXs and UIs for them.
On Sun, Feb 1, 2015 at 3:32 PM, Carl Karsten <carl at personnelware.com> wrote:
> Yes and no.
>
> json.dumps is a yes.
>
> same with "get from server" response = session.get(url)
>
> There is code to serve stuff as a web server, but for very limited values
> of stuff. django helps by making it easier to serve more stuff.
>
> And all of these have various parameters to address the various details
> that have been glossed over, or might be of use to someone else, but not
> you, but you get to read the docs for them anyway as you try to figure out
> if they will work for you.
>
>
>
>
> On Sun, Feb 1, 2015 at 1:29 PM, Randy Baxley <randy7771026 at gmail.com>
> wrote:
>
>> Shouldn't these be functions that are part of JS and Python?
>>
>> On Mon, Jan 26, 2015 at 8:48 PM, Carl Karsten <carl at personnelware.com>
>> wrote:
>>
>>> We can do better than the bits of code in veyepar. I grabbed it because
>>> I had that handy, but it is more complicated than a simple example.
>>>
>>> (for those of you wondering, it's some ajaxy login that I tried to keep
>>> isolated https://github.com/CarlFK/veyepar/tree/master/dj/accounts )
>>>
>>>
>>> On Mon, Jan 26, 2015 at 4:11 PM, Randy Baxley <randy7771026 at gmail.com>
>>> wrote:
>>>
>>>> veyepar is not forgotten just not yet understood and I am guessing only
>>>> one side of a solution that needs to be broken out and documented to create
>>>> a tutorial.
>>>>
>>>> On Mon, Jan 26, 2015 at 2:46 PM, Carl Karsten <carl at personnelware.com>
>>>> wrote:
>>>>
>>>>> I think this needs to be broken into parts:
>>>>>
>>>>> 1. code to serialize data.
>>>>> 2. code to parse stuff. (deserialze)
>>>>> 3. code to get stuff from a web server.
>>>>> 4. code to serve stuff as a web server
>>>>> 5. code to serve serialize data as a web server.
>>>>>
>>>>> 6. build the client and server from the above.
>>>>>
>>>>> and just lines of code isn't enough.
>>>>> #1 could be simply
>>>>> import json
>>>>> >>> json.dumps(1.0)
>>>>> '1.0'
>>>>>
>>>>> But I think it is worth looking at how cpython implements a float,
>>>>> why can python functions pass those bytes around but you shouldn't
>>>>> chuck those bytes at a http client that is asking for it.
>>>>>
>>>>>
>>>>> On Mon, Jan 26, 2015 at 2:29 PM, Randy Baxley <randy7771026 at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I am talking about Visual CTA Chicago's front end and back end. I
>>>>>> only try to code on it because I have been unable to Tom Sawyer anyone else
>>>>>> into doing it.
>>>>>>
>>>>>> It really is fun though and a real kick when in a tall building where
>>>>>> you can see the trains and buses doing what your code says they are doing.
>>>>>>
>>>>>> On Mon, Jan 26, 2015 at 12:11 PM, Chris Foresman <foresmac at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> If you’re talking about your own front end and back end, I’d avoid
>>>>>>> using XML for data. JSON is really the only data format most web services
>>>>>>> uses these days—it requires much less processing to encode/decode, and
>>>>>>> every major language tends to have constructs that map directly to/from
>>>>>>> JSON. XML was only ever meant for machine reading, true, but I’ve never run
>>>>>>> into an API that used it unless it was built in Java.
>>>>>>>
>>>>>>>
>>>>>>> Chris Foresman
>>>>>>> chris at chrisforesman.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Jan 26, 2015, at 12:04 PM, Randy Baxley <randy7771026 at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> You are of course correct. For buses Harper Reed's server per David
>>>>>>> Beazley's Pycon talk has been useful during initial development and
>>>>>>> something like that will be set up when moving to production. The current
>>>>>>> problem is much simpler. Just wish to set up a server and pass information
>>>>>>> back and forth between frontend and backend.
>>>>>>>
>>>>>>> On Mon, Jan 26, 2015 at 11:42 AM, Chris Foresman <foresmac at gmail.com
>>>>>>> > wrote:
>>>>>>>
>>>>>>>> From my experience working with the CTA’s byzantine API, you’re
>>>>>>>> better off writing your own proxy server that periodically polls data about
>>>>>>>> stop locations from the tracker service and maintaining your own database
>>>>>>>> of locations. Use that to figure out what stop or stops are applicable and
>>>>>>>> then use a translating shim to request data on buses or trains for that
>>>>>>>> location.
>>>>>>>>
>>>>>>>>
>>>>>>>> Chris Foresman
>>>>>>>> chris at chrisforesman.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Jan 25, 2015, at 9:12 AM, Randy Baxley <randy7771026 at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Sorry, the to should be:
>>>>>>>>
>>>>>>>>
>>>>>>>> https://github.com/randy7771026/Visual-CTA-Chicago/blob/master/sbte.py
>>>>>>>>
>>>>>>>> On Sun, Jan 25, 2015 at 9:09 AM, Randy Baxley <
>>>>>>>> randy7771026 at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Thank you Tanya though not what I am looking for, I think. If I
>>>>>>>>> can ever get anything working in Django it might be an option.
>>>>>>>>>
>>>>>>>>> For now things are extremely simple but they will get very
>>>>>>>>> complicated as the code grows.
>>>>>>>>>
>>>>>>>>> Right now I want to pass the latitude and longitude from:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://github.com/randy7771026/Visual-CTA-Chicago/blob/master/index.html
>>>>>>>>>
>>>>>>>>> to:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://github.com/randy7771026/Visual-CTA-Chicago/blob/master/index.html
>>>>>>>>>
>>>>>>>>> replacing lines 48 and 49. Then my python does things and writes
>>>>>>>>> some things that I will want to send back to the web side but then
>>>>>>>>> eventually back to python. CTA still uses XML so for now I am thinking I
>>>>>>>>> want to stay with that format but in the future may switch to one of the
>>>>>>>>> more modern formats.
>>>>>>>>>
>>>>>>>>> I will eventually have to decide if I want to create cookies or
>>>>>>>>> keep a database and issue uids and pswrds.
>>>>>>>>>
>>>>>>>>> On Thu, Jan 22, 2015 at 8:30 AM, Tanya Schlusser <tanya at tickel.net
>>>>>>>>> > wrote:
>>>>>>>>>
>>>>>>>>>> I cannot make it to Project night, but may I recommend Tablib
>>>>>>>>>> <http://docs.python-tablib.org/>, another Kenneth Reitz gem,
>>>>>>>>>> that does just what you asked?
>>>>>>>>>>
>>>>>>>>>> http://docs.python-tablib.org/en/latest/tutorial/
>>>>>>>>>>
>>>>>>>>>> >> I am wondering if we might be able to build a tutorial that any
>>>>>>>>>> >> Grey Haired legacy programmer could understand for this process
>>>>>>>>>> >> that addresses the parsing of XML, JSON, XSON and cookies when
>>>>>>>>>> >> designing and implementing a project then include that in the
>>>>>>>>>> project
>>>>>>>>>> >> night resources.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Chicago mailing list
>>>>>>>>>> Chicago at python.org
>>>>>>>>>> https://mail.python.org/mailman/listinfo/chicago
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Chicago mailing list
>>>>>>>> Chicago at python.org
>>>>>>>> https://mail.python.org/mailman/listinfo/chicago
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Chicago mailing list
>>>>>>>> Chicago at python.org
>>>>>>>> https://mail.python.org/mailman/listinfo/chicago
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Chicago mailing list
>>>>>>> Chicago at python.org
>>>>>>> https://mail.python.org/mailman/listinfo/chicago
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Chicago mailing list
>>>>>>> Chicago at python.org
>>>>>>> https://mail.python.org/mailman/listinfo/chicago
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Chicago mailing list
>>>>>> Chicago at python.org
>>>>>> https://mail.python.org/mailman/listinfo/chicago
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Carl K
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Chicago mailing list
>>>>> Chicago at python.org
>>>>> https://mail.python.org/mailman/listinfo/chicago
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Chicago mailing list
>>>> Chicago at python.org
>>>> https://mail.python.org/mailman/listinfo/chicago
>>>>
>>>>
>>>
>>>
>>> --
>>> Carl K
>>>
>>>
>>> _______________________________________________
>>> Chicago mailing list
>>> Chicago at python.org
>>> https://mail.python.org/mailman/listinfo/chicago
>>>
>>>
>>
>> _______________________________________________
>> Chicago mailing list
>> Chicago at python.org
>> https://mail.python.org/mailman/listinfo/chicago
>>
>>
>
>
> --
> Carl K
>
>
> _______________________________________________
> Chicago mailing list
> Chicago at python.org
> https://mail.python.org/mailman/listinfo/chicago
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20150201/c56c3dce/attachment.html>
More information about the Chicago
mailing list