robsearles.com Report : Visit Site

Technical data of the robsearles.com

Geo IP provides you such as latitude, longitude and ISP (Internet Service Provider) etc. informations. Our GeoIP service found where is host robsearles.com. Currently, hosted in United Kingdom and its service provider is Rackspace Ltd. .

the related websites

ibrow.com na.org.au cer.org.uk neworleansairlift.org officehelp.biz spanish.typeit.org wellcomeimages.org eugeneportman.com livepartners.com buydomainnames.co.uk 

HTTP Header Analysis

HTTP Header information is a part of HTTP protocol that a user's browser sends to called nginx/1.4.1 containing the details of what the browser wants and will accept back from the web server.

DNS

HtmlToText

rob searles struggles of a self-taught programmer about gpg identity disqus and code formatting conflict? posted june 5, 2013 by rob & filed under general . i’ve had reports that the code formatting isn’t working for some of you out there. i haven’t been able to replicate this, after testing on multiple machines and browsers. however i think it is due to a plugin conflict: namely the plugins for the disqus comments and wpsyntax code formatting. if you are reading any of my posts and notice that the formatting doesn’t look overly pretty, please could you help me out and see if you are having any javascript errors on that page. if so, please let me know so i can try to fix them. for reference, the code highlighting is looking like this for me: if you’re not getting the same i’d really appreciate it if you could help me track down why. backbone reactive – introducing the dashboard posted june 4, 2013 by rob & filed under backbone reactive . tags: backbone , javascript , jquery , reactive , requirejs , zepto this is part five of the backbone reactive tutorial . for all sections, please view the table of contents . so far we’ve been working on a simple one page application. now we want to introduce another page – the dashboard. for simplicity sake for this project, we are going to have the dashboard page display just two items: some user details and the latest message. note: you can find all the source code to this project on github , this chapter has been tagged ch5-dashboard return values and callbacks you can see the full code in commit d68d75d . i won’t go into too much detail as most of it is self explanatory and stuff we have already been over. however there is just one slight thing to look out for in the render() method of the main dashboardview . render : function ( ) { var self = this ; ... var userdetails = new userview ( ) ; self.$el. append ( userdetails. render ( ) ) ; var messageview = new messageview ( ) ; messageview. loadmessage ( function ( el ) { self.$el. append ( el ) ; } ) ; } , the userdetails should be quite straight forward. all it is doing is appending the return value of the userview ‘s render() method to the dashboardview ‘s dom element. the render() method simply returns the view’s el property. render : function ( ) { ... return this . el ; } , the loadmessage() method is doing almost exactly the same thing, but because it is having to retrieve some json from the server, so instead of returning the el property to passes it as a parameter to a callback: loadmessage : function ( callback ) { var self = this ; self. model . fetch ( { success : function ( ) { self. render ( ) ; callback ( self. el ) ; } } ) ; } , copy/paste naughtiness look at the code in dashboard.js . do you see something horrible going on? yes. most of it is just copied and pasted from list.js . this is fantastically bad practice. what if we want to change how the “nice date” is formatted? we’ll have to change it in multiple places. nope, this type of coding will not do. we need to turn our attention to reusing components. conclusion ok, so now we have multiple pages within our application. but we have bodged this together and it isn’t very elegant. there is a load of copy and paste nastiness going on which i don’t much like, and this is something we’ll address next time. but why would we want a multi-page application in the first place? one reason is that it supports a fallback version much more easily – we could have a simple html website with multiple pages as the fallback version and then layer the multi-page backbone app over the top. another reason is that this sort of html structure also helps with seo, especially with a well chosen url structure to match. finally, and this is a much more subjective and personal reason, it just makes more sense in my head. if the application has a number of different sections (dashboard, inbox, settings etc) then to me it make more sense to break it down into the distinct sections. multi-page or single page, this is your choice. reminder: you can find all the source code to this project on github , this chapter has been tagged ch5-dashboard listening for changing events posted may 28, 2013 by rob & filed under backbone reactive . tags: backbone , javascript , jquery , reactive , requirejs , zepto this is part four of the backbone reactive tutorial . for all sections, please view the table of contents . we now have a simple application that allows us to load data in from a server (mocked in our case), display a list of results and then display specified further information based on a mouse click. we are explicitly triggering an event, listening for it and carrying out a corresponding action based on the triggered event. but what about events that we don’t manually trigger? what happens when something changes without our interaction but we still need to respond to it? this is what listento() is for. note: you can find all the source code to this project on github , this chapter has been tagged ch4-listen data and template changes to demonstrate how the listento() method is used we are going to include a new property in the listitem model called isread . this is a very simple boolean property either false if the message hasn’t been viewed or true if it has. before we can include this in the application we first need to make some data and template changes. within the mock data for the list we must add the isread property, for example: {"id": 5, "date": "1357643063000", "subject": "testing the backbone reactive list page", "from": "rob", "isread": false } next we should update the html for the list, first the header within the listview : var html = '<h1>backbone reactive list (from json)</h1>' + '<p>this is generated from json data. it isn \' t very special but ' + 'there is enough going on to be a useful demo' + '<table border="1"><thead>' + '<tr><th>time</th><th>date</th><th>subject</th><th>from</th><th>read</th></tr>' + '</thead><tbody></tbody></table>' ; within the actual listrowview we need to display a more human readable form of the boolean, so instead of true and false , how about yes and no ? render : function ( ) { ... var isread = 'no' ; if ( this . model . get ( "isread" ) ) { isread = 'yes' ; } // later i'll be converting this to a template, but for the time // being it will suffice var html = '<td>' + timenice + '</td><td>' + datenice + '</td>' + '<td>' + subject + '</td><td>' + from + '</td><td>' + isread + '</td>' ; this .$el. append ( html ) ; return this ; } , as discussed before including the html directly within the javascript is very bad practice and we will remedy this in a later chapter, but for now it will suffice. updating the model when we view the message we want to update the isread property from false to true . this is very simple using the model’s set() method. probably the easiest place to change this for us when we load the message, after we have fetched the data. we should update the loadmessage() function that is called when we want to load the message to display. all we have really done below is add the functionality for setting the isread property to true for the current listitem model associated with messageview . loadmessage : function ( model ) { var self = this ; self. model = model ; self. model . fetch ( { success : function ( ) { self. model . set ( 'isread' , true ) ; self. render ( ) ; } } ) ; } , updating of the view now we are amending a property within the listitem model so now we want to be able to listen for this change and update the listrowview associated with this model accordingly. this too is simple, all we need to do is when initializing the listrowview listen for changes to the associate model. if there are any changes, re-render the view. initialize : function ( ) { this . listento ( this . model , "change" , this . render ) ; } , this should have the effect of refreshing the particular row, changing the “read” column from “no” to “yes”. however, a mistake earlier means that instead of simply re-rendering and replacing the specific row it re-renders and appends the updated row to the html. to change we need to stop appending the row to the dom and instead just set the html within listrowview change: render : function ( ) { ... this .$el. append ( html ) ; return this ; } , to: render : function ( ) { ... this .$el. html ( html ) ; return this ; } , and now it should simply replace the html, working as expected. conclusion we are really motoring along with backbone now and utilising some of its most powerful features. from this chapter we can see that it is relatively simple to layer further functionality over the top of a basic application. this is great for trying things out, but also great for building up an application over a number of iterative sprints. the listento() method allows for disperate components of the application to stay updated on the states of each other and respond accordingly. this in itself cuts down on a lot of foo.on(event) type fluff. so far we have just been tackling a single page application. next time we move it up a gear to a multi-page app. reminder: you can find all the source code to this project on github , this chapter has been tagged ch4-listen backbone reactive – adding in events posted may 21, 2013 by rob & filed under backbone reactive . tags: backbone , javascript , jquery , reactive , requirejs , zepto this is part three of the backbone reactive tutorial . for all sections, please view the table of contents . so far the list page doesn’t do anything apart from list the messages we have. this means that it is less functional than the static html fallback site – at least with that one you could view the message contents. so in this post we are going to build on our simple backbone app , adding in events so you can actually view the messages. luckily adding events in backbone is simple. within the listrowview all you have to do is add: events : { "click" : "open" } , open : function ( ) { console. log ( "clicked: " + this . model . id ) ; } , now when you reload the page and click on a row you should see the console output the id of the model you clicked on. so now we know we can click on a row, we need to load in the data and display it. note: you can find all the source code to this project on github , this chapter has been tagged ch3-events let’s tackle this in reverse order and create a new view to display the message contents, we’ll call it messageview : var messageview = backbone. view . extend ( { id : 'message' , render : function ( ) { var date = datefunctions. getdate ( this . model . get ( 'date' ) ) ; var datenice = datefunctions. getdateandtimenice ( date ) ; var html = '<p><label>from</label> ' + this . model . get ( 'from' ) + '</p>' + '<p><label>date</label> ' + datenice + '</p>' + '<p><label>subject</label> ' + this . model . get ( 'subject' ) + '</p>' + '<p>' + this . model . get ( 'body' ) + '</p>' ; this .$el. html ( html ) ; // if the message view is not already attached to the page, simply // append it into the body if ( ! $ ( "body" ) . children ( "#" + this . id ) . length ) { $ ( 'body' ) . append ( this .$el ) ; } } } ) ; there is nothing too special going on here. all this view currently does is to render a bunch of html, using the properties of its model for the values. you may spot a new object called datefunctions . this was a simple utility object created as now we are displaying the data in two views (the listrowview and the messageview ). the big questions about this view are: – how does it get the data to display? and – where is it called from? when working through this initially i started to initiate and load the messageview directly in listrowview when the event was clicked (see /57e9e5f/). however, this lead to the two undesirable outcomes. firstly messageview would have been repeatedly initialised every time someone tries to view a message. this isn’t too big a deal, but it is not efficient when we could initialise once and be done with it. secondly, as the messageview would be initialised every time we want to view the message, when the view renders and injectes itself into the dom we needed to add logic to stop it adding itself multiple times to the page. there are a couple of ways to solve this. one method (although i didn’t try it) would possibly be to create a singleton class for the message viewer, this would have stopped the reinitialisation issue. the method i went for in the end was to “bubble” the event up, from the list row to the main list view. as all the listrowviews would bubble up the event, we would only need to call the messageview once and then listen for the “view message” event to re-render the message viewer. we use the backbone trigger functionality to bubble up the event. (recall that the open function is called when a row click event is detected). open : function ( ) { this . trigger ( "viewmessage" , this . model ) ; } now, in the listrowview we make two changes. within the initialize function we initialize messageview . initialize : function ( ) { ... this . messageview = new messageview ( ) ; } , and then during the rendering process, when looping through the listitems we add a listener to the listrowview instance and when a viewmessage event is detected, we instruct the messageview instance to load the message based on the model passed with the event. self. collection . each ( function ( listitem ) { var v = new listrowview ( { model : listitem } ) ; v. render ( ) ; // listen for the "viewmessage" event, loading the message whenever it is triggered v. on ( 'viewmessage' , function ( model ) { self. messageview . loadmessage ( model ) ; } ) ; self.$el. children ( "table" ) . append ( v. el ) ; } ) ; the method to load the message within messageview is very simple, all it does is to tell the model passed to (re)fetch it’s data and then renders the view. var messageview = backbone. view . extend ( { id : 'message' , loadmessage : function ( model ) { var self = this ; self. model = model ; self. model . fetch ( { success : function ( ) { self. render ( ) ; } } ) ; } , ... } ) ; finally, to finish this all off we must update the listitem model ever so slightly, informing it where it should load in the data, by setting the url. this is slightly more complicated than the listcollection url as we need to specify which message we want to load in, so have to add the model’s id to the url. var listitem = backbone. model . extend ( { url : function ( ) { return '/mock-data/message.' + this . id + '.json' ; } } ) ; an example of the mock data we will load in is: { "id": 1, "date": "1357643063000", "subject": "testing the backbone reactive list page", "from": "rob" , "body": "lorem ipsum dolor sit amet, consectetur adipiscing elit. quisque ornare, ligula a tincidunt cursus, lorem magna ullamcorper enim, ut interdum nisi quam vel lorem. aliquam aliquam sem eu ipsum pretium ut bibendum quam blandit. duis vel blandit nibh. vestibulum mattis sapien eros, ut iaculis quam. suspendisse potenti. ut eleifend massa a libero adipiscing porttitor in ut nunc. sed lobortis pretium consectetur. morbi convallis, velit sit amet placerat vehicula, dolor lorem sollicitudin enim, at convallis tortor ipsum vel lectus. fusce eget tellus sit amet nisl interdum volutpat. etiam congue nibh id quam scelerisque posuere." } conclusion we are really starting to get to the meat of backbone js now. the ability to automatically get fresh data from the backend (or in our case the mock json data) and then the views to be updated without having to worry about jquery calls or complex logic is really powerful stuff. reminder: you can find all the source code to this project on github , this chapter has been tagged ch3-events . overlay a simple backbonejs application posted may 15, 2013 by rob & filed under backbone reactive . tags: backbonejs , javascript , jquery , reactive , requirejs , zepto this is part two of the backbone reactive tutorial . for all sections, please view the table of contents . now the static fallback content has been created and is working, we start overlaying a basic backbone application over the top. we will leave the homepage for the moment, coming back to that later on in this project. for now we will concentrate on the list page. the functionality of the list page is very simple: all it does is replace the static content on the list page with some dynamically generated content from json data retrieved by an ajax call. note: you can find all the source code to this project on github , this chapter has been tagged ch2-simple . dependencies in the list.html page we simply need to load in the required javascript files for our application. obviously there is backbone, but we also need to include its dependencies, underscore and either jquery or zepto. in our case we will use jquery for the time being, as it is the framework most people are familiar with. (as we progress with developing for mobile devices we will be investigating zepto as a replacement). <script type="text/javascript" src="/js/jquery-1.8.3.min.js"></script><script type="text/javascript" src="/js/underscore-min.js"></script><script type="text/javascript" src="/js/backbone-min.js"></script> once we’ve loaded in our dependencies, we need to load in our actual application file: <script type="text/javascript" src="/js/app/list.js"></script> it is this file, list.js that does all the work. there is quite a lot going on in this file, even for a simple app such as this, so let’s brake it down piece by piece. jslint it is a good idea to lint your javascript code. the main reasons for this is to give all your code a consistency so it is easier to come back to later. it also catches any silly typos or bugs along the way. for linting this project, i am using the slint nodejs module, the lint command used is: jslint -indent = 2 --plusplus --vars . / js / app / list.js jslint can be a bit bossy, so you’ll notice that the first few lines in the code are simply there to keep there to keep jslint happy. 'use strict' ; var backbone ; // hello jslint var $ ; // hello jslint now we have the tedium of keeping code tidy out the way, we can move onto the actual meat and potatoes. models reading through the rest of the list.js file, you’ll see that it follows a pattern of building up each needed component one at a time. firstly a listitem model is defined. this very simply extends the base backbone model . var listitem = backbone. model . extend ( { } ) ; this line is so simple because backbone models are so powerful. but why do we need a model in the first place? the way i think about it, models are the basic units of data within a backbone application. they are the smallest piece of complete information within context. for example, in our project, the smallest piece of complete information is an item of the list. this item itself has smaller pieces of data, such as a date or subject , but without the wider context of the item itself, these tiny pieces of data make no sense – they are not complete. models don’t just contain data, they also have logic handling that data: validation, access control etc as well as events bound to that data. for example, if the ui changes a property of the model, this can trigger an event so other parts of the ui can react. this is why they are so powerful. however, for our purposes we are going to explore none of that right now. instead we’ll move onto collections collections whilst models provide the individual bits of data, backbone collections , as their name suggests, collate these individual bits of data into one group, or collection. the important thing to remember about collection are that the models within them are ordered. this allows us, for example, to load in ordered data and have this order honoured within the collection. when defining a collection we want to start using dynamic data. backbone has built in functionality for this, which greatly reduces the amount of code needed to be written for ajax calls etc. to start using dynamic data in a collection we must specify a url. this url is for the ajax request when we call the collection’s fetch() method. (for the purposes of this tutorial we are simply using mock json data, not a dynamic backend). as we want the data to load in straight away we call the fetch() method in the initialize function, passing it any callback options. backbone has another built in method – parse() – to interpret the data received within the response from the ajax request. in our case, we simply want to return exactly the data that we fetched from the mock json file. var listcollection = backbone. collection . extend ( { model : listitem , initialize : function ( models , options ) { this . fetch ( options ) ; } , // as we don't really care for the backend in this demo, we have // hard-coded some json data to use in the application url : '/mock-data/list.getlist.json' , parse : function ( response ) { return response ; } } ) ; as with the models, collections are simple, but powerful. for reference, the format of the json data returned is as follows: [ {"id": 5, "date": "1357643063000", "subject": "testing the backbone reactive list page", "from": "rob" }, {"id": 4, "date": "1357642823000", "subject": "another exciting subject line", "from": "john" }, {"id": 3, "date": "1357641983000", "subject": "i just love dancing", "from": "billy" }, {"id": 2, "date": "1357565783000", "subject": "possible expansion plans", "from": "wilhelm" }, {"id": 1, "date": "1357563263000", "subject": "can't think of anything witty", "from": "susan" } ] views backbone views are where the action really gets going. now we have defined our data and how it is organised, we need to start using that data. what this means for us is that we need to start displaying this data within the browser. the way i like to think about views is that they represent individual components or groups of components within the user interface. in our current list page we have broken it down into two views: - a view for the complete list, in our ui this is a table - a view for the individual list elements, or table rows in our case this relates very closely to collections (for the complete list) and models (for the individual rows). in fact, backbone allow us to attach both models and collections directly to views during initialization. something we will look at in a moment. first we define the view for the table row, or list item: var listrowview = backbone. view . extend ( { tagname : "tr" , classname : "list-row" , .... } ) ; setting the tagname property to tr means that when inserted into the dom, this view will be a table row element. we also add a class name, thinking about it i’m not sure why, possibly just because we can. right now, this view is a little useless, so we need to implement the render() method: render : function ( ) { this . id = this . model . get ( "id" ) ; // i am not spending too much time on the date formatting or // making it look nice, i just need enough so it works var date = new date ( parseint ( this . model . get ( 'date' ) , 10 ) ) ; var timenice = this . padtime ( date. gethours ( ) ) + ':' + this . padtime ( date. getminutes ( ) ) ; var datenice = date. tolocaledatestring ( ) ; var subject = this . model . get ( "subject" ) ; var from = this . model . get ( "from" ) ; // later i'll be converting this to a template, but for the time // being it will suffice var html = '' + timenice + '' + datenice + ' ' + '' + subject + '' + from + ' ' ; this .$el. append ( html ) ; return this ; } , the first thing to notice is that we are associating the id of this view instance with that of the view’s model. this is important when it comes to triggering and responding to events later. however, we have neatly glossed over where the model comes from. how does the view contain a model from which it can use it’s id? as mentioned above, views can have collections and models attached to them during initialization. jumping ahead of ourselves slightly, in the listview view, we can see that when we loop through the collection of items, we initialize the listrowview passing it a listitem model instance. self. collection . each ( function ( listitem ) { var v = new listrowview ( { model : listitem } ) ; ... } ) ; the rest of the render() method is pretty self explanatory (if not incredibly quick and dirty, we will fix this in a later post). we first clean up some of the model’s properties so they are suitable to be displayed to the general public. next we build the html for the table row and then append this html to the table row element the view represents. finally, we return ourselves as is convention. so that is the individual table rows sorted. next we need to look at the complete list as a whole. as ever, we simply extend the base backbone view: var listview = backbone. view . extend ( { } ) ; however, unlike the listrowview we are going to define an initialize method: initialize : function ( ) { var self = this ; self. collection = new listcollection ( { } , { // the success function is used for the fetch callback success : function ( ) { self. render ( ) ; } } ) ; } , this is doing three very important things so let’s pay close attention to them. firstly it is initializing the listcollection. as described above, the act of initializing this collection will fetch the data from the mock json we have and assigning the results to itself. secondly we are assigning this listcollection to be the current collection for this view. this will allow us to access the collection data and contained models far easier later on. finally, once the data has been loaded and the view’s collection populated we render the view. render : function ( ) { var self = this ; var html = ' [ edited for brevity ] ' ; self.$el. html ( html ) ; self. collection . each ( function ( listitem ) { var v = new listrowview ( { model : listitem } ) ; v. render ( ) ; self.$el. children ( "table" ) . append ( v. el ) ; } ) ; return self ; } , as we have already dealt with the most important part of this render method above, the rest of it should be pretty self-explanatory. however, to quickly summarize we are first creating a bunch of html represented by this view (yes yes, i know! we will move it to a template in a later post) and then injecting it into the dom. next we loop through each model in the collection, initializing a new view for each model and then appending that to the table element we have just injected into the dom. finally, we return the view itself as is convention. running the app finally, now all the models, collections and views have been defined, we can run the app. this is simply a case of initiating the listview, applying it to a specific dom element. in our case it is #content . that is it. to test it out, fire up the _server.js nodejs http server and navigate to http://localhost:7777/list.html. you should see a table of list items, which has been entirely populated by your backbone application. congratulations. the first step is complete. on to events. reminder: you can find all the source code to this project on github , this chapter has been tagged ch2-simple . bank holiday reading 6 may 2013 posted may 6, 2013 by rob & filed under general . tags: links to start of with, we have a great story about a game developer releasing a game about game development and what happens when the pirates were pirated. as i find myself tumbling down the rabbit hole of lisp and it’s derivatives, this article was very timely for me. an interesting read and makes me want to roll my sleeves up yet further. to continue the lispish theme, this post about chicken scheme did not disappoint. a really great read for the weekend. looks like a very interesting blog to follow. just to reinforce the point that the atomic object’s blog was worth following, here is another good post . this time it is about reading code. back to the lisp theme. i have had sicp on my bookshelf for a number of years, but never really tackled it. this article by brian harvey reminds me that i probably should give it another go. finally, if you have had enough reading for the week, watch this 15 minute tedx talk about what we can learn from linus torvalds. backbone reactive – fallback version posted may 2, 2013 by rob & filed under backbone reactive . tags: backbonejs , jquery , reactive , requirejs , zepto this is part one of the backbone reactive tutorial . for all sections, please view the table of contents . the first thing we should always do, when building any application that relies heavily on the frontend javascript is to produce a fallback version. the reasons are pretty straight forward: if a user visits your application and for whatever reason they don’t happen to javascript enabled, then they will still be able to get some value out of your site. this will obviously be heavily reduced value, but it is better than nothing, of even worse, a message saying “you need javascript” it is always handy for seo purposes to have at least some content on the page, not just a link to a javascript file which will generate the content. (more…) backbone reactive – introduction posted april 30, 2013 by rob & filed under backbone reactive . tags: backbonejs , javascript , jquery , reactive , requirejs , zepto this is part zero of the backbone reactive tutorial . for all sections, please view the table of contents . at the end of 2012 i began playing around with backbone.js . one of the things i was very keen on was producing a site that used a single codebase but could handle desktop, tablet and mobile version with minimal effort – so called “reactive design”. this series of posts is the culmination of my experimentation, problems faced, decisions made and lessons learned. there will be roughly 15 posts in this series (not sure an exact number as they are still being written, tweaked, combined and expanded. i aim to publish one per week, but if i have the time i’ll try i’ll try and up the frequency. i hope you enjoy. you can find all the source code for this tutorial in the git repo . org-mode, shared agenda file list posted march 27, 2013 by rob & filed under emacs . tags: emacs after watching a chat between sacha chau and john wiegley about emacs, i’ve gone on an emacs rampage. i tweaking my init script to use org-mode (probably more on that another day) and generally getting things ticking along quite nicely. i use three different computers (desktop at office, desktop at home and laptop) and all my org files are kept in sync via dropbox. however, one thing that has irritated me with this setup is the facts that whilst the files are shared between the three machines, which of the org files are considered agenda files is not. on each machine i have to keep on adding files into the agenda list with c-c [ . i have a number of different agenda files (one for each project or sub-project i’m working on) so files are added to and removed from the list quite frequently. it would be great if the lost of agenda files could be sync’d too. as ever in emacs, there is a way. in this case it is the variable custom-file . you can get more information about this variable using the describe-variable command ( c-h v then enter custom-file ) so, to change the location of the custom file, all i needed to was to add the below to my init file: ;; ensure that any custom variables are synced via dropbox ( setq custom-file "~/dropbox/emacs/custom.el" ) ( load custom-file ) hurray for emacs! testing org2blog posted march 26, 2013 by rob & filed under emacs . tags: emacs , org-mode this is a very quick test of posting to my wordpress blog using org2blog . as such, it’s probably not going to be very long, but hey, it’s a test. heading level two what does this look like. clearly this is very exciting! now, how to publish… ah, c-c p . after publish edit well, that was surprisingly easy! i could get used to this. 1 2 3 4 5 6 7 >> last topics emacs general javascript linux lisp/scheme lua open source opinion php reviews servers tutorials backbone reactive pages about gpg identity links twitter github g+ © 2018 rob searles.

URL analysis for robsearles.com

http://www.robsearles.com/page/3/
http://www.robsearles.com/2013/05/bank-holiday-reading-6-may-2013/
http://www.robsearles.com/tag/javascript/
http://www.robsearles.com/tag/links-2/
http://www.robsearles.com/page/5/
http://www.robsearles.com/tag/reactive/
http://www.robsearles.com/tag/zepto/
http://www.robsearles.com/page/6/
http://www.robsearles.com/page/7/
http://www.robsearles.com/category/php/
http://www.robsearles.com/category/javascript/
http://www.robsearles.com/category/reviews/
http://www.robsearles.com/category/opinion/
http://www.robsearles.com/tag/org-mode/
http://www.robsearles.com/2013/06/disqus-and-code-formatting-conflict/

Whois Information

Whois is a protocol that is access to registering information. You can reach when the website was registered, when it will be expire, what is contact details of the site with the following informations. In a nutshell, it includes these informations;

Domain Name: ROBSEARLES.COM
Registry Domain ID: 1560660901_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.meshdigital.com
Registrar URL: http://www.domainbox.com
Updated Date: 2017-06-13T00:00:00Z
Creation Date: 2009-06-28T00:00:00Z
Registrar Registration Expiration Date: 2019-06-28T00:00:00Z
Registrar: MESH DIGITAL LIMITED
Registrar IANA ID: 1390
Registrar Abuse Contact Email: [email protected]
Registrar Abuse Contact Phone: +1.8779770099
Reseller: Paragon Internet Group Ltd (Daily)
Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited
Domain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Registry Registrant ID:
Registrant Name: Rob Searles
Registrant Organization: ibrow Wood & Searles
Registrant Street: Legiendamm 14
Registrant City: Kreuzberg
Registrant State/Province: Berlin
Registrant Postal Code: 10179
Registrant Country: DE
Registrant Phone: +44.02071832328
Registrant Phone Ext:
Registrant Fax Ext:
Registrant Email: [email protected]
Registry Admin ID:
Admin Name: Rob Searles
Admin Organization: ibrow Wood & Searles
Admin Street: Legiendamm 14
Admin City: Kreuzberg
Admin State/Province: Berlin
Admin Postal Code: 10179
Admin Country: DE
Admin Phone: +44.02071832328
Admin Phone Ext:
Admin Fax Ext:
Admin Email: [email protected]
Registry Tech ID:
Tech Name: Rob Searles
Tech Organization: ibrow Wood & Searles
Tech Street: Legiendamm 14
Tech City: Kreuzberg
Tech State/Province: Berlin
Tech Postal Code: 10179
Tech Country: DE
Tech Phone: +44.02071832328
Tech Phone Ext:
Tech Fax Ext:
Tech Email: [email protected]
Name Server: ns1.daily.co.uk
Name Server: ns2.daily.co.uk
DNSSEC: unsigned
URL of the ICANN WHOIS Data Problem Reporting System: http://wdprs.internic.net/
>>> Last update of WHOIS database: 2017-07-20T12:54:14Z <<<

For more information on Whois status codes, please visit https://icann.org/epp


The Data in this WHOIS database is provided
for information purposes only, and is designed to assist persons in
obtaining information related to domain name registration records.
It's accuracy is not guaranteed. By submitting a
WHOIS query, you agree that you will use this Data only for lawful
purposes and that, under no circumstances will you use this Data to:
(1) allow, enable, or otherwise support the transmission of mass
unsolicited, commercial advertising or solicitations via e-mail(spam);
or (2) enable high volume, automated, electronic processes that
apply to this WHOIS or any of its related systems. The provider of
this WHOIS reserves the right to modify these terms at any time.
By submitting this query, you agree to abide by this policy.

LACK OF A DOMAIN RECORD IN THE WHOIS DATABASE DOES
NOT INDICATE DOMAIN AVAILABILITY.

  REGISTRAR MESH DIGITAL LIMITED

  REFERRER http://www.meshdigital.com

SERVERS

  SERVER com.whois-servers.net

  ARGS domain =robsearles.com

  PORT 43

  SERVER whois.meshdigital.com

  ARGS robsearles.com

  PORT 43

  TYPE domain

DOMAIN

  NAME robsearles.com

NSERVER

  NS1.DAILY.CO.UK 195.26.90.11

  NS2.DAILY.CO.UK 31.170.127.155

STATUS
clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited
clientTransferProhibited https://icann.org/epp#clientTransferProhibited
clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited

  CHANGED 2017-06-13

  CREATED 2009-06-28

  EXPIRES 2019-06-28

  REGISTERED yes

Mistakes

The following list shows you to spelling mistakes possible of the internet users for the website searched .