HTTPS everywhere is nice... except if your current web host makes free HTTPS hard because they make money from selling certificates.
141 karma · joined May 28, 2015
Ultimately language use requires a few skills:
* a good parser * motor cognition/coordination * a good memory * semantics/context * vocabulary * situational awareness
The first two in the list are what small children struggle with the most. Fortunately, we can eliminate motor coordination as a need for AI. Although extremely powerful parsers demand a specialized expertise to produce this part of the problem is straight forward. I write open source multi-language/multi-dialect parsers as an open source hobby.
I discount vocabulary and situational awareness, because most children still haven't figure this out until they enter high school long after they have learned the basics of speech. That pattern of human behavior dictates that while it might be hard to teach these skills to a computer you can put this off a long ways down the road until after basic speech is achieved.
If somebody paid me the money to do this research my personal plan of attack would be:
1. Focus on the parser first. Start with a text parser and do audio to text later. Don't worry about defining anything at this stage. When humans first learn to talk and listen they are focusing upon the words and absolutely not what those words mean.
The parser should not be parsing words. Parsing words from text is easy. The parser should be parsing sentences into grammars, which is harder but still generally straight forward with many edge cases.
2. Vocabulary. Attempt to define words comprising the parsed grammar. Keep it simple. Don't worry about precision at first. Humans don't start with precision and humans get speech wrong all the time. This especially true for pronouns. Just provide a definition.
3. Put the vocabulary together with the parsed grammar. It doesn't even have to make sense. It just has to have meaning for words and the words together in a way that informs an opinion or decision to the computer. Consider this sentence as an example: I work for a company high up in the building with a new hire that just got high and gets paid higher than my high school sweetheart.
4. If the sentence is part of a paragraph or a response to a conversation you can now focus on precision. You have additional references from which to draw upon. You are going to redefine some terms, particularly pronouns. Using the added sentences make a decision as to whether new definitions apply more directly than the original definitions. This is how humans do it. These repeated processing steps means wasted CPU cycles and its tiring for humans too.
5. Formulate a response. This could be a resolution to close the conversation, or it could be a question asking for additional information or clarity. Humans do this too.
6. Only based upon the final resolution determine what you have learned. Use this knowledge to make decisions to modify parsing rules and amend vocabulary definitions. The logic involved is called heuristics.
This only way all this works is to start small, like a toddler, and expand it until the responses become more precise, faster, and more fluid. At least.... this is how I would do it.
* All current package managers are either language or OS specific. What if you have an application with code written in multiple languages?
* NPM didn't have any kind of integrity checks for its packages, and I assume most package managers don't either. If you download a corrupt package, for example, you won't have any idea and it will still install.
* Some package managers do better than others with regards to managing packages. I found NPM encourages dependency hell and very little management tools for dependent or installed packages.
* A lot of package managers seem to intermix packaging, distribution, and a registry. The registries tend to have limited names to pick from (like real estate) and can result in legal problems. Also if registration to the service catalog is required you cannot self-host or self-manage the distribution of your application.
I am trying to work on a solution to these problems at https://github.com/prettydiff/biddle
Consider these statements:
* "Tom is a genius", which implies the Tom solution is a trusted asset beyond improvement, doubt, or questioning. It also implies the solutions provided by Tom are golden unimproveable truths.
* The various statements from Scott suggest an indisputable faith in process and convention.
Clearly there are failures at multiple levels here. First of all Tom sounds like a whiny bitch. These personality types are inherently defensive and typically seek to reinforce an individual's position of self triumph in a small pond. Toxic.
Secondly, Scott has a lot of faith in process and conventions. Processes and conventions are the absolute enemy of creativity. I understand processes are necessary to establish a certain level of security, but they more typically exist to satisfy some OCD insanity where there is comfort in doing things in a particular way without consideration for why they are done in that way. Many developers cannot tell the different between security and superficial stupidity. Many technology abstractions enable that stupidity thereby convolute the differences between security and OCD stupid which only enables additional stupidity.
All of the prior mentioned failures are allowed to exist because the management doesn't want to be involved until there is a problem, such as Tom crying. This is called enabling.
Most important of all is that all technology should be questioned, doubted, and challenged. Obviously this sort of continuous improvement is utterly absent, because everybody has a competing agenda.
I know of several people who choose to not waste their time with Facebook. Seriously, why? Any time I need to nudge somebody, that I don't care enough to bother with in the real world, there is Linked In. Everybody else either has my phone number, email address, or they are people I don't know.
As long as the majority of voters think of Trump as a broke racist narcissist and Clinton as an apathetic or unethical elitist he may well have a chance.
http://heatst.com/politics/gary-johnsons-polling-numbers-rea...
Many posters in here indicate oddness that a military force could represent secularism. I am curious why that is. Most uniformed militaries I have observed have always seemed more secular than the people they represent. Let us not forget the Islamic Brotherhood was democratically elected in Egypt, which attempted to instill sharia law. A military coup ended that nonsense. Also, Hitler was democratically elected and was not immediately supported by the military.
https://www.fortworth.com/about/neighborhoods-districts/cult...
Soon Fort Worth will over take San Fransisco in population, and at the last recession was far less disrupted economically. Speaking purely from data and statistics Fort Worth is more diverse than San Fransisco with regards to ethnicity, religion, nationality, and so forth. And I doubt there is a substantial difference in the diversity of food options since I have been to San Fransisco. The weather and public transit are likely superior though.
Otherwise, if I were single and had 10x the income I would likely agree that the bay area is a more fun place to be.
Seriously... why should a smaller house cost nearly 10x more in the same country? You won't be paid 10x less where the cheaper houses are.
What many people don't understand is that a wrong decision is better than no decision at all. The world isn't going to wait for you to call an assembly and have a cordial discussion about how to delicately make a possibly-suicidal suspect feel happy. It sure as hell isn't going to wait for to conduct an online survey to discover what makes people less sad. People are dying. The suspect is threatening to have explosives and claims to want to kill more people. The first order of business is to eliminate the threat. This is an active shooter incident. Once negotiations failed the only right decision is how to terminate the suspect. This is operational doctrine.
Stalling and feeling it out is a horribly bad decision to make and indicates a lack of professionalism for active shooter scenarios.
That is a huge guess. After 10 officers are shot I doubt the SWAT team was in a guessing mood.
> he wasn't going to get the opportunity to leave.
This is perhaps the most commonly fallacy I have read in this thread. Immobility does not immediately equivocate to either a reduction or increase in potential threat. The guys on the ground have to make that determination based upon the evidence available in the moment. After 10 officers were shot I am sure the suspect vocalizing additional threats likely didn't help the SWAT team believe the risk was diminishing.
The intention to commit further harm is evident from statements by the accused and the vile nature of the crimes. Given the potential for harm, that the negotiations failed, and threats of explosives this was the safest course of action. Whether or not the suspect was surrounded has little bearing on if the threat was reduced or increased.
> If there was time to repurpose the bomb-dispoal bot, were there not also non-lethal ways to apprehend the suspect?
That is a flawed argument in that it guesses a quantity of time to modify a robot and time to neutralize an armed suspect are equivalent. It is also flawed in that it presumes there is a choice to be made. Another flaw is that doesn't account for the fact that the robot might already have been modified earlier in case negotiations failed, and if so then the robot is already modified and immediately ready while the suspect isn't.
If this is what it took to end the suspect's life, thereby preventing further harm, then so be it and congratulations.
Yes, I write all my personal projects in human order. To me human order is when the flow control of human consumption and computer execution are most closely aligned. I attempt to achieve this with depth and order.
1) Have a giant library that defines your library or application.
2) Inside the giant function nest child functions for the primary tasks in the order with which they will execute. In the case of the following example the options evaluation is first, followed by the lexer/parser is the second child task, followed by various code presentation tasks, and finally by an analysis task. http://prettydiff.com/lib/jspretty.js
3) Break the child tasks down, as necessary, into reusable components.
4) I also believe a reference should always be declared before it used, which can dictate the order of reference declaration.
My opinion is that when the flow control of the application is unclear you are wasting time during maintenance. You may not know where a problem is occurring, but if the flow of the application is immediately clear from reading the code you immediately know where to start, where to step to next, and where to stop. There is minimal guessing and it doesn't require breakpoints to figure it out.
As a counterpoint everybody follows a chain of command. In all the corporate jobs I have held I never experienced a chain of command noticeably different from the military. Just like in corporate world the military allows you some latitude to push back on your leaders if they make a completely disastrous decision. The primary difference there is that you are more motivated to push back if a bad decision could mean increased risk to security (people's lives). I have never experienced this level of critical impasse in the corporate world.
The military is mostly like working for a corporate employer with some key differences:
* In theory the military expects everybody to be a leader, though in practice not everybody is willing to step up and make leader-like decisions or in some cases toxic leaders will suppress the opportunity.
* The military is a really big bureaucracy, which can constrict many creative (unorthodox) leadership decisions, but sometimes produces extremely unorthodox solutions to work around the bureaucracy.
* There are points in the military where you are demanded to work really long hours (like 12-16 hours, 6 or 7 days a week). In that amount of time everybody's personality is hyper-amplified. Some people can make this work really make their teams gel, where other people become terminal destructive forces.
* The military is often really bad at a constant work pace. Consider the phrase "hurry up and wait". You tend to get really good at accomplishing tasks at 4x human speed so that you can go back to being paid to self-study or watch movies.
* Look at how hard your corporate CEO works, the number of simultaneous tasks they have to balance, and the constant uncertainty in their schedules and travel. When you deploy in the military the entire team works at that tempo all the time.
* You don't get to be a conformist tool as a military technician, because then the bureaucracy will crush your soul. You quickly learn to invent your own solution to many common problems. This is substantially less true of many corporate software developers.
It is important to instead concede that you don't know the needs of the consumers in the higher level, and if you think you do it is because you are guessing. The only way avoid the problem is to not attempt to move into the higher level, at least not intentionally and not through business priorities.
This is extremely counter-intuitive because there are generally fewer expenses and greater market frequency at each higher level, which means superior revenue potential. Businesses exist to make money and to ignore moving up to the higher level means denying this potential (vast) revenue source.
This doesn't mean you can't move into the higher level of the stack and be really good at it. It just means you cannot do so both intentionally and as a business objective.
The solution is to double-down on where you already are with what you are already good at and focus on product quality of your existing products. Continue to improve where you are already good. Improvements and enhancements to existing products can gradually yield the next level as the improvements progressively open new potential in an evolutionary fashion. While getting to the next level this way is much slower it is also risk reduced and continues to associate your brand with quality and consume satisfaction.
This will only work, though, if the goal is improving the current product and not acquiring revenue in that desired higher level. Think evolution and not revolution. It has to be a gradual, almost accidental, increase of capability based on meeting current consumer needs.
When writing HTML be as descriptive as possible in your use of tag names. If you only use "div" and "span" for everything you are failing your users and destroying accessibility. Go read this http://www.w3.org/TR/WCAG20/ and the various supporting documents. You cannot claim to have mastered HTML if you have failed to understand accessibility.
CSS just takes practice. With the browsers being less divergent now and easier to code for its harder to learn a deep deep level of mastery. Back in the days of IE6 you had to become quite the badass to make CSS work cross-browser without a bunch of stupid hacks.
For JavaScript there are some key things to focus upon:
* The scope model (learn closures and nesting functions)
* events and callbacks
* xmlHttpRequest (AJAX)
* the DOM
* the Node.js methods
Don't dick around wasting time learning frameworks and JQuery. Just learn through the vanilla code and learn to solve problems as directly as possible. It will pay off in the long run. Pass your code through the http://jslint.com/ tool. JSLint is OCD crazy opinionated and extremely strict, but it is that on purpose. It is designed to teach defensive coding practices so that you can right code correctly the first time which has a significantly lower probably of failure and is easier to maintain.