hxxps://github(dot)com/ytisf/theZoo/tree/master/malwares/Binaries/Ransomware.Petya
1,979 karma · joined November 15, 2012
hxxps://github(dot)com/ytisf/theZoo/tree/master/malwares/Binaries/Ransomware.Petya
The hash part of the URL, (#andmorestuff) is not sent to the server by the browser, however the query string is. (?var=stuff&another=otherstuff)
Using this to send the search to the server is smart, since the server can respond with data without an additional round-trip AJAX request. However, everything in the URL, other than the hash is read-only by client-side scripts. So, if you want the URL to reflect the search, you can either a) reload the page using the query string, or b) follow the single page app methodology, and manipulate the query string with the data, and change it using an AJAX request.
Google's interactivity, with the smoother feel of not seeing an entire page refresh (plus potentially less data being sent over the wire after the initial load) could be simply stored in an internal state. However, should the user refresh, the search would be lost. If you try going to a Google search with a search query hash, you'll notice a brief delay before the search results are displayed.
For example, in this link: https://www.google.com/search?q=original#q=newsearch
The page loads, but there's an AJAX request to the /search route with the hash-specified query, with query string parameters to specify how the data should be served. Still, the client-side script cannot strip the query string of the previous search without a full page reload.
While the info leakage is annoying, it's unavoidable in this strategy.
Note: The browser history, and subsequently the URL can be manipulated through the History API's pushState, which could be a direction Google could go in, but IMHO, the hash approach is viable as well.
https://developer.mozilla.org/en-US/docs/Web/API/History_API
I seriously had no idea.
https://np.reddit.com/r/legaladvice/comments/3iycro/fl_i_am_...
It seems like it could be in parallel to your situation. I highly recommend having someone evaluating your dosage, as well as whether it's an adverse effect of the Adderall itself.
>I miss Google wave invites going for $26 a month (srikarg.github.io)
>Ask HN: Is there a good, standard capped convertible note paperwork?
>NSA leaks: David Cameron cracks down on Apache Quitting JCP: 'Oracle Is the Fear of Macros (techcrunch.com)
>RSS.gd: the RSS icon was mistaken for the end of the Union at CoreOS Fest 2015 – Call for New Startup BitcoinDeals is Launching its Own URLs? (technokyle.com)
So far it's worked for me.
I definitely agree no Dev should write their own gateway. There are great ones out there who are developed by people who are paid to do nothing but that.
1) It needs some serious design work as it stands right now.
2) I'll probably open source it in the future.
3) I'm planning on making the UI more intuitive, and more clear as to what everything does.
4) I'd love to hear what you guys think :)
Of course, I imagine this is a non-trivial feature, and there are likely better approaches.
Super awesome job guys!
AutobahnPython 0.10.4
I am not Web server, but a WebSocket Endpoint.
You can talk to me using the WebSocket protocol.
You can see a little bit more in main.js as well. As for the backend, it's looking like Python, considering the WS page. I am curious about 3 and 4 as well, and as the actual frameworks used for 1.Very nice work to the person who made this.
Edit: I'd also love to know if this ever is open sourced. Understandable if not. Very cool tool.
JetBrains' WebStorm
Node.js
MongoDB
Redis
MySQL
MyCLI
Git
GitLab (Hosted and Self-Hosted)
Gulp
FireBug
Trello
Slack
CircleCI or Travis, depending on the project
WakaTime
I'm sure I'll find some more that I missed on my own list as well.