Steps to mitigate.
1. Setup SPF immediately. You can validate your records here- http://www.kitterman.com/spf/validate.html
You'll have to know who you send email through and their SPF record, but a quick googling of "provider name SPF" should get you what you need.
Depending on your DNS provider the results may be instant.
2. Filter those bounces keep them out of your inbox - it's going to take while until this clears up.
3. Make sure that YOU are not hacked, check the headers of the bounce back messages here - http://mxtoolbox.com/EmailHeaders.aspx
Ensure that your IP or hostname is not listed there. (This includes web servers that your domain is hosted on, apps that send on your behalf etc)
4. You can check to see if your domain is black listed - http://mxtoolbox.com/blacklists.aspx probably not...but worth a check.
TL;DR - I run one of the largest spam filtering companies in the world. Happens all day to clients...it's one of the reasons people switch to us.
DKIM - https://support.google.com/a/answer/174124?hl=en
SPF - https://support.google.com/a/answer/33786?hl=en
Dmarc - https://support.google.com/a/answer/2466580?hl=en
However, implementing needs support from your email/hosting provider.
Disclosure: I'm not at all affiliated with Postmark, I use their free tier transactional emails, and I use their DMARC tool.
If you fully and correctly implement SPF, DKIM, and DMARC, you'll see a massive improvement as much of the SPAM gets dropped completely at recipient MTAs.
To fully solve the problem, you need something to filter the backscatter . At the time I purchased Postini, but now that Google has bought them, Google Apps for Work seems to have this feature built in. There may also be software you can run on your own server, or other proxy services like Postini. I've not looked since I use Google Apps for work. Such filters simply track all outgoing messages you send, and reject bounces from addresses and domains you never emailed.
This has complete solved my problem. Now I only get regular SPAM, a fact of life now.
In practice, all these things together look like this for kogir.com:
@ IN TXT "v=spf1 redirect=_spf.google.com"_dmarc IN TXT "v=DMARC1; adkim=r; aspf=r; p=reject; pct=100; rf=afrf; ri=86400; rua=mailto:firstname.lastname@example.org; ruf=mailto:email@example.com; sp=reject;" mail._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCFlfDA1Gpz8BQVpcNsiDkSp6ayVCWKlfeYXhiW0CaCgJJJkBpZj9E9OGMGUSAFFgEhCs8wf/fZCx9jsWkH34joEuylNnBnGt8exPSokLwrtubTQajOZcUgbpUlxwyCkyuE41mbpYUfWkPCOaRTa1VqZVWYs+ZdEkYaKXh9UALYeQIDAQAB"
It's quite common to see people have their gmail accounts hacked and used for spam.
Unfortunately, the model 3 isn't scheduled to come out until end of 2017 (if that holds true) and my lease runs out in March of 2017 so... gonna have to wait until the round after this coming one (generally lease for 3 years at a time).
But if it was coming out sooner and it's visually appealing - yes, I'd have probably put down a deposit tonight. Assuming it's not god awful ugly; which I can't imagine it will be.
I believe in the current gen electric vehicles much more than I believe in current gen internal combustion vehicles, but that could be a side effect of being one of the affected VW TDI owners.
It's a refundable reservation so I didn't mind putting money down first, and then seeing specs tonight.
So in a round about manner, the market is betting that many people here won't be buying one, or that TSLA won't be able to deliver on it in a timely manner.
I did some competitions (Design and Development) on TopCoder during undergrad days and was lucky enough to secure a place in top 3 couple of times. Key there is to choose a contest with less number of participations and patience.
Other than that, weworkremotely.com helps, browse some recent whoishiring threads. Might want to have a look at jobcombinator.io as well.
There are websites that specialize in WFH work such as weworkremotely.com or wfh.io. Not sure they advertise a lot of contracting position, but it doesn't hurt to apply and specify that you are interested in being a contractor.
Another approach: all this spam you get on linkedin from recruiters/hiring managers. Just start reading them and reply with "I'll do it. Remotely and as a contractor". Most won't be interested, but a few may go for it.
Second, get plenty of quality sleep, that means no caffeine/alcohol for 6-8 hours before bed, and allowing yourself at least 8 hours of uninterrupted sleep.
Third, when working, get up and walk around once an hour, for at least five minutes. Have a healthy snack, do some push-ups, walk around the block, anything but sit.
Fourth, exercise! Do something that makes you sweat for at least 30 minutes a day. This one is a must, no excuses.
Fifth, stretch. This can be done during your five minute breaks. If you do nothing else in this list, do wrist flexor and extensor stretches (look them up). Otherwise, your coding career can get cut short (speaking from personal experience). Stretching takes 2-3 minutes and can make a world of difference; do them every time you're feeling stale. It's not possible to stretch too often.
Next, eat right. Keep your diet light, skip the soda and chips; eat fruits, nuts and veggies, drink water. You're already sitting on your ass all day, don't make it worse by fueling yourself with garbage.
Finally, have some hobbies that don't require a screen. Go hiking or biking. Play a sport. Learn an instrument. Bird watch. Build a tree-house. Catalog all of the different bugs in your yard. Whatever, just get away from screens.
All of this is obvious and a no-brainer, right? Well, look at the people who have been in a field for 20-30 years, the ones who stick to the above are easy to spot; they're the fit, happy, healthy people. The others are easy to spot too, because they look like hell. Get into these habits before you need to, you'll be saving your future-self a lot of trouble.
Hope that helps. Time for my workout...
- it forces me to focus only on code when I'm coding, since 9gag/Reddit/Facebook aren't available, and
- it forces me to get up and walk around and do physical things when I'm taking a break from coding
I find I am less fatigued and about as efficient, even if it means building a queue of Googleable bugs/questions that I return to when I'm back on the internet.
You can code 12 hours a day, but compare the code in your first 4 hours to your last 4 and see what I mean.
Just stop coding. Do other stuff.
I find that I can extend that quality window by spreading it out more. Don't do 4 hours in a block. Do an hour, or 1.5 hours and break for 30mins. Clear the head again. Then go back, you can do this more - leading to > 4 hours of quality code
Hammock Driven Developmenthttps://www.youtube.com/watch?v=f84n5oFoZBc
When you feel better, come back to it--you aren't any worse for doing so!
The reason for this is because I know C this way, so every time I write a line of code in C, I instinctively visualize what's going on under the hood.
I would like to be able to visualize this same thing with js.
Or, as others said, learn something outside of technology. Learn how to play an instrument, or how to write fiction, or how to paint, or how to ballroom dance (if your health permits).
None of my business, but out of curiosity: What kind of illness gives you that long a recuperation time?
If you have just met 1 month ago, your chances or not making it long-term are above 50%. I'm sure you're aware of that. What most people don't do, to follow-through with that fact, is to require vesting. There has to be a way for such an unstable team to blow-up and break up.
It should be a legal entity now because equity is under consideration by at least one person now. Anything else creates more issues than it solves. Better to have a hard conversation that ends in a split now than after months of tiptoing around the landmine.
I rarely enter an interactive debugger. I have TONS of logging statements I can toggle. I make program execution as deterministic and reproducible as possible (for example, all random numbers are generated from random number generators that are passed around). When something goes wrong, I turn on (or add) logging and run it again. Look for odd stuff in the log files. If it doesn't make sense, add more logging. Repeat.
I worked on a pretty large videogame in the 90s where /everything/ was reproducible from a "recording" of timestamped input that was automatically generated. The game crashed after half an hour of varied actions? No problem, just play the recording that was automatically saved and attached to the crash report. It was amazing how fast we fixed bugs that might otherwise take weeks to track down.
What is a debug statement, anyway? You're checking the state at a point in the code. That's exactly what a unit test assertion does... except that a unit test calls a single method/function... meaning the code you're trying to debug needs to be split up and written in a way that is easily unit-testable, with few, if any, dependencies that aren't explicitly given to it... which makes it better code that is easier to reason about (and thus results in fewer bugs).
See where I'm going with this? TDD = say (mostly) goodbye to "debugging"
As a Python/JS developer a few print/console.log statements are usually all it takes for me to figure out what's wrong with something. For more thorny situations there's always PDB/chrome dev tools.
At the end of the day, the people who are the best at debugging things aren't that way because of the tools they use. They're the best because they can clearly visualize the system, how data is flowing through it, and where potential problems might arise. Intuition from dealing with other similar problems also helps.
Sometimes debug printfs out a UART or USB if my system lets me, sometimes I'll create a log in memory if I can't printf or if the issue is timing sensitive (which a lot of my work is).
Pen & paper end up being very useful too - often writing out what I'm thinking helps me figure out what's going wrong faster than poking around the code or circuit board.
(1) Just add debug statements near where the bug is happening. These print a string, and the name and value of variables. Printed values in Lisp are human-readable, not just a pointer.
(2) Trace selected functions. This outputs the function name, arguments, and return value on function entry and exit.
(3) Use the virtual machine debugger. I can set breakpoints, display the stack, and trace VM instructions, but it's most useful for printing out disassembled compiled code.
(4) Browse data structures in Firefox. While my Lisp is running, a web browser runs in another thread, and every symbol has its own URL. Data structures are displayed as HTML tables.
(5) Unit tests. I've used these to debug complex algorithms, e.g. for event handling, and type inference.
I've never read about specific methods on how to do this "by the book". I'm usually doing ( for NodeJS ) :
1. Set a breakpoint inside my NodeJS 2-3 lines before the exception that I got.
2. Run debug mode
3. Do what I need in order to reach the breakpoint
4. Analyze the variables inside ( via watch ) or run code in that function ( via console )
Helps a lot more than `console.log(some_var_before_exception);` :D
Only after I've grappled with these questions will I move onto log analysis, printfs, the debugger, data fuzzing, etc.
Debuggers are great, but the knowledge gained by using them to solve a problem is completely lost once that close button has been pressed.
Also if I'm having to use a debugger to work out what's going on, usually it's a good sign my code is overly complicated...
I'm interested about FalcorJS, does anyone use it ? I found it very interesting, check this out for more at: https://reactjs.co/2016/02/03/what-is-netflix-falcor-and-why...
- If I do not know what's the problem, I do everything in my power to reproduce the bug and maybe write a test (as small as possible) that triggers the bug. I enable logging or write a special log function to track relevant state in case the bug is rare.
- Once I know what triggers the bug, I should know the general direction of where in the code it is. I start printing various variables and parameters in case it's a low-hanging fruit like wrong sign or stuff like that.
- If I do not succeed with that, I comment out half of the code and look if the bug persists. If it does, then I know it's in the other half. If it does not, then I know it's in this half. I proceed with this binary search until I am down to 1 statement, which takes a logarithmic amount of steps. I found the bug. I fix it. (This does not work if the bug is in two places or if the bug is a bad memory operation that triggers a bug later)
- Real debuggers like valgrind are rarely necessary if you're familiar enough with the program. In fact, unless you're dealing with the hairiest of hairy memory problems and heisenbugs, you probably do not need a debugger at all. Debuggers are useful to debug e.g. generated assembly when you write a compiler.
If it's something i think is trivial i'll just use a few print statements. This is 90% of the time.
If i end up with too many print statements then i step into the debugger. Others scoff at debuggers, which is odd because they can be powerful tools. Maybe you only use it once every couple of months, but they can be very helpful. When you're waist deep in the stack, or dealing with action at a distance, trying to fix something in poorly factored code, want to watch a variable, think there's some weird timing issue, need to step down into libraries beyond your control, then debuggers can help.
Don't think of the debugger as a debugger, think of it as a REPL. You just happen to be using the REPL with buggy code.
If I can narrow it down to what line, or even file, is throwing an error I just take a few minutes, read all the code and all the code of branching methods, and then can narrow it down to a single line.
From there it is actually developing a fix. As you mess around with more and more languages, you will notice that most compilers lend something far from a helping hand.
This only works, and I will stress this, for programs under 1 million lines. Past that mark, you need to do some extra steps.
When I debug one million line projects, I narrow it down to a file. I pull out the code from the file, and I mock all of the methods that file calls (This gets REALLY hard with networked code. Trust me). From this small subset, I slowly break the functionality of the external method until I resemble the error being made in the main project. From that I now know the method(s) that are actually causing the problem.
But, there is one thing that this makes an assumption about: your compiler is working.
Put blatantly, they're crap.
Usually they won't show you the correct file causing the error or they will not generate a helpful error. Runtime errors are even worse.
The best thing to do is avoid making the tricky errors. Make unit tests, using fuzzing tests, and well made documentation.
Documentation alone, that details all of the possible output and input states of the function will save you days on some bugs.
In Java, the @Nullable tag is a godsend. Use these features, they WILL help.
If you do tests, fuzzing, and documentation.
Using your brain and some things to make your brain's job easier will make you faster at debugging then any debugger like your buds GDB/DDD setup.
1. Reproduce the bug as consistently as possible.
2. Find a pivot for the bug. Whether this is a previous commit where the bug did not occur, or a piece of code that can be commented out to clear the bug, I need to find some kind of on/off switch for the behavior.
3. I comment out code / insert break points / use git bisect to flip the switch on and off, performing a kind of binary search to narrow the scope of the issue until I have it down to one line or method.
4. Once the source is found, read the surrounding source code to gain context for the error and reason toward a solution.
Of course, this works best if the bug originates from a single source. Sometimes this is not case and there are multiple variables interacting to create the undesirable behavior. Thats when things get really fun :)
So imagine doing things like narrowing down execution to just before and just after your error, then taking snapshots of the runtime memory and diffing the objects. Or a conditional breakpoint that changes the class of a particular instance to a special debug class.
You can do many of the same things in compiled languages, I've since discovered, if you have a decent incremental compile set up, and you use some tactical thinking. But the environment always seems like it's trying to get in your way. (As opposed to a good dynamic environment, which seems more like an eager golden retriever wanting to play more fetch.)
in the olden days when i used ide's like visual studio or netbeans, i'd often times leverage their native debuggers to set watchpoints and step through code. but those days are over, now i mostly use interpreted languages like python, ruby, and compiled languages like golang (highly recommended). print statements are the way to go, especially if you're writing server side code (restful apis, websockets, etc), you'll want the log information as you won't be able to attach a debugger to a production system.
just a random thought based on this topic, if debug/log/print statements were detailed enough, one could actually take a log file and write some code to parse that and transform into test cases in your favorite test framework, that may have some effect on saving time writing test cases. for production bugs, you could take the log output as the reproducer steps to generate test cases to cover this.
and i really liked the comment about tdd and more importantly unit testing, it's critical and helps developers better organize their code.
When debugging difficult, intermittent problems (e.g. non-repro crashes) my strategy is to keep a log of when it occurs, add lots of diagnostics and asserts around where I think the problem is, until hopefully I can catch it in the debugger or notice a pattern.
90% of the work of debugging is creating a quickly reproducible test case. Once you have that you can usually solve it.
Desktop apps w/ C/C++ -- IDE based debugger (Visual Studio, GDB w/ a front end, ADB) print / logging statements
Embedded C -- IDE Debugger (Green Hills, ARM DS-5, IAR, Eclipse w/ remote GDB, etc) GPIO ports, logic analyzers, oscilloscopes, etc)
Apps -- ADT / ADB, print / logging statements
Python, bash, sh, .bat scripts -- print / logging statements
As many others have mentioned, having a consistent bug reproduction methodology is vital, a strong mental model of the SW and its various components is important, and a willingness to dive deep and question assumptions is critical. Ie don't always expect your compilers or various OSes to be infallible.
Being able to quickly reproduce the bug time and time again makes a big difference. Some permanent verification that it's actually fixed (at least in the given case) at the end of the session is also nice and adds a lot when doing a major refactoring or something similar. Especially for bugs related to the domain specific requirements, rather than the technical ones.
However I do use gdb from the command line on occasion. Code I write is pretty heavy on global variable and with gdb you can poke about and see what they are. You can also use gdb to look at internal processor modules.
To get around the limits of not being able to use break points I have a command line interface built into the firmware, which I use to poke and prod for debugging. I'm dimly aware that almost no one else does this, but can't for the life of me figure out how people get by without it.
I also have a critical error handler that can save information off to a no init section of memory and then reset, recover and then log the error via the serial port on startup and via the radio. This is useful because for instance I have that hooked into the bus fault interrupt, so I can pull the offending instructions address off the call stack. The binutils program addr2line.exe rats out the offending line of code about 99% of the time.
For timing related stuff I make heavy use of toggling port pins and watching what happens with an oscilloscope.
For networking stuff sometimes I use wireshark.
For C#/.net development I use Visual Studio and logging either to a window or to a file. However I've noticed that when other programmers work on my code they immediately delete that stuff and switch to printing to 'stderror'.
For most bugs I look at, I usually wish that Linux had DTrace. I can't tell you how many weird bugs I've found where finding the solution would've been debugged in 20 minutes of DTracing. For example, I'm currently investigating a weird memory leak in Docker that actually appears to be a reference leak in the Go runtime. It took me several days to figure out it was a bug in the runtime (if I had DTrace I could've found symptoms of the issue much faster).
But in general, most of the bugs I find can be debugged with some print statements if I can correctly make an educated guess where the bug lies. For other sorts of issues, unit tests or creating minimal test cases works pretty well and for everything else I'll jump into a debugger if it's really necessary.
In Python I mostly rely on print(f) debugging, especially when working on multiprocessing programs, which I do rather frequently. With multiprocessed Python, pdb is useless. pdb is great, but not for a multi-process program. Most of my issues are related to sub-optimal API documentation that fails to point out argument types, and find I do a lot of trial-and-error programming, for which printfs are great. Occasionally I drop into `import pdb; pdb.set_trace()` to inspect objects or the REPL to try out ideas.
In Perl and shell, which I use ever more infrequently, the equivalent of the printf debugging is the norm. The only language I have found the debugger to be the first choice has been Java.
With Rust, I find myself resorting to a debugger surprisingly seldom. Its type system and the safety checks in the compiler catches most of the mistakes I make.
I dont do much C programming anymore, but if I did, I would be interested in using rr (http://rr-project.org/), which allows you to record a run of the program and replay it _exactly_ as it was the first time, essentially letting you reproduce and fix race conditions.
Set a breakpoint in the code, refresh the browser, and all the variables in the scope will be annotated with their value at break time.
This is really what you're after when you're println debugging - it has the advantage of showing you everything in a minimally intrusive way which is helpful when you don't know what you're looking for exactly.
But not all the bugs are easy to solve. The worst kind of bugs are hard/impossible to reproduce. For them my approach is to suspected places where it could occur and add logging, and just wait until it occurs again(sometimes it takes weeks or even months). So I am trying to log how the data flows through the system by isolating the direction to look for.
For example: I'm yet to find cause of the mystery of the MS Word and TinyMCE, where sometimes it will not strip out microsoft's formatting. It only occurs about once a month. I wrote a simple alert script which sends me an email when this happens and I can get to the person in seconds(most of the users are in the same office), and try to reproduce the exact moment when it occured on users computer.
My fix was just show an error asking users to repaste exact same text which then works as expected.
But I think IDE's can't beat real-time debuggers, like console.log or Ruby's bettererrors gem, having full real-time access to application logic/code at the spot, you can't beat that.
Logging doesn't give you anywhere near the power the a good debugger does.
Statically-typed language? Dynamic? Makes a difference.
Point is, 90% of whatever answers you receive here will not be well-suited to your particular situation.
If you do that right, you can skip the reading and go right for the beef. Breakpoint.
Last but not least - good architecture, worst heisenbug wont cost you as much as the smallest architecture error.
I also output my code to .dot format to visualize the flow of data quite a bit. This is extremely useful in statemachine like stuff - I basically can create animated gifs (well, not really, it's more of me pressing right on my image viewer) to watch how my programs execute.
Why not Delve? I do actually use Delve. Just not as much as logf()s and panic()s.
Hmm.. in retrospect, I also dump a lot of data (neural network weights for example) into csv for debugging
Probably says something about my coding practices that I've gotten good at it.
But since I work on consumer desktop software, occasionally a customer will encounter a problem that I can't replicate on my dev machine, and their bug description doesn't help me locate the problem. In that case, I try to duplicate the customer's system as much as possible: I have Parallels Desktop & VM images of almost every version of Windows, and I can configure the amount of RAM. Sometimes it's easier to ask the customer to run a special Debug build, but if they're not very tech savvy, Parallels can often help me reproduce the bug myself.
Snapshot debuggers like Google Cloud Debugger are probably the way forward. Alas it doesn't support Python 3 yet.
That being said, I'm not trying to take anything away from log-based debugging, there have been many times when log-based debugging has saved my bacon, but it feels strange that there is almost an attitude of interactive debuggers being "lesser" in these comments.
Then just put a conditional breakpoint and wait for it to confirm the error and break. Once there I can probably reason backwards to an earlier state that led to the error condition such as "an item must have been removed from a placed order" so again a conditional breakpoint in the remove method with the condition that the order is already placed. Rinse repeat.
One thing I have found helpful is to compile the code using different compilers and on different platforms. A bug that is hard to reproduce on one OS can become deterministic on another OS.
I do use the perl debugger though when I am writing perl and when there is a need. The benefit to this debugger is that it comes built into the language.
I've also gotten into the habit of building SDL projects in Visual Studio to use the console so I can just dump whatever I want into it.
I'm probably an example of what not to do in many cases, but still get the job done.
std::cout << "got here" << std::endl;
gdb on OS X is such a horror show.
Anyone who'd like to learn a more systematic debugging process should take it.
If there is no Exception and there is som kind of logic bug.I search my way to the logic code with the issue by greping and reading.
When i have found the approximate location of the issue i will probably set up some var_dump's or log.Println in the code to get a better understanding of what is happening.
After that it is usually a done deal.
Windows during development: Visual Studio.
Windows prod: DebugDiag to get the dumps, combo of VS, DebugDiag and the various native debuggers for analysis. Dumps created by the user or the system are also input.
Windows event tracing is also absolutely fantastic IF you have it.
I feel no shame.
Usually, my goal then is to either:
1) Find a configuration / infra issue we can solve (best outcome for everyone)2) Give the most info to dev to enable a code fix, and roll back/mitigate in the interim.
In the last few years, people have paid me lots of money to build these really cool ELK or Splunk log chewing systems for them, which I have to admit, are utterly useless to me. There are really great monitoring tools which give me historical graphs of stuff I usually don't care about too.. but... I, and most of the folks I run with don't really reach for these tools when we hit a prod issue as the first resort.
Lets say, hypothetically, a customer of mine has an issue where some users are getting timeouts out on some API or another. We got alerted through some monitoring or whatever, and so we start taking a look.
First step, for me is always login a webserver at random (or all of them) and look at the obvious. Logs. Errors. dmesg. IO. Mem. Processes. The pretty graph ELK tools can tell me this info, but what I want to look at next is easier to jump to when I'm already there, than trying to locate IOWAIT in something like splunk.
All looks good on the web servers. Ok. Lets check out the dbs in one term and the apps in another. You follow the request though the infra. Splunk or ELK can tell me one of my apps is eating 25,000 FDs but then what? I need to login anyway. Next on the list are tools like strace/truss, iostat, netstat and so on which will immediately tell you if it's an infra/load/config issue, and we go from there. Down into the rabbit hole.
The point I'm trying to make is; for me at least, the tools we're deploying and being paid well to deploy now like dataloop, newrelic, splunk and so on are actually useless for solving real-time prod issues (for me personally, and my crew, at least) because they only expose a very small amount of info, and almost regardless of the issue I'll need to be on the box looking at something unique to the problem to either explain the impact of it or to mitigate it.
As I said though, I'm a recovering ops person and I'm doing dev these days. I still tend to use print statements when I hit a bug; although since I'm now mostly doing Erlang, bugs are rare and usually trivial to track down.
Next most important thing is the network requests tab-- seeing what data is coming back from the server, if any, is indispensable.
If I'm debugging minified code that we haven't set up source maps for yet, I'll find a string literal in the source to match up the minified code to unminified code so I can see what I'm doing anyway by looking back and forth.
When I have to reproduce a bug, I often use the FormFiller extension for Chrome to quickly navigate our forms without having to fill them out.
I use EditThisCookie (another Chrome extension) to modify or view the cookie as I work, or to delete it to start a session from scratch. I don't like Incognito mode because I don't have my extensions and it doesn't maintain breakpoints when the tab is closed and reopened.
With regards to the call stack, being able to black-box certain scripts is awesome. You can right click a script in the sources explorer on the left side of the DevTools and black-box it, which will stop it showing up in the call stack. No more jQuery / Angular / Underscore calls cluttering my callstack!
What else...whenever I'm debugging CSS I always just do it in DevTools so I can see changes on the fly to figure out the problem.
I also used to use the handy "debugger" statement now and then, although I use it less and less these days since it's the same as a breakpoint but takes slightly more effort. Mostly only use it when I already have the code open in my editor and don't feel like manually finding that point in execution in the DevTools....it's kind of like "go-to this line."
Ctrl+P in sources of DevTools allows fuzzy search among files. Which is awesome.
There have been times I've used the XHR breakpoints, Event Listener breakpoints, and DOM breakpoints, but it's really rare for me. Definitely though there are cases where I'm not sure where an event is originating from and these have very much come in handy at those times. Underneath those on the right of the sources you can also see a total list of all active event listeners, which is also nice.
I'll add more thoughts if I think of anything else...I guess I'm mostly talking about my tools here. With regards to my thought process, that's more complex...hmm. I guess I try to figure out what the desired behavior is, try to see what the actual behavior is and how consistent it is, then see if I can find the code that controls that part of the application. If I don't already know, I Inspect Element on the page, find an element id or something, then look it up in our code and follow the trail to whatever's controlling the page and relevant behavior. From there it's just careful examination of the logic to find the flaw, using all the tools above.
Interrogate every assumption you make.
Or the equivalent for whatever language I'm using.
I have played around with node-inspector, but I have found that it's awfully slow, particularly with really large arrays or objects. So I eventually just abandoned it. It seems like a good idea, and might be worth revisiting in the future.
Does it really need to be able to handle a very high volume of small requests right now? When there's no code, no customers and no use, yet, there's no profile showing evidence of a performance bottle neck.
To put it another way, the first order problem isn't technology, it's product market fit and finding customers. That means getting a "conversation starter" up and running is a task on the critical path and "what infrastructure might be necessary if Facebook signs up" is not.
So if the person can build a conversation starter in Java and iterate on it more quickly than they can learn node.js then the answer is pretty obvious -- assuming the question is "how do I build an enterprise product?" It's less obvious if the real question is "what should I learn?"
I'll add that in terms of tooling [such as the aforementioned profiler] and scaling infrastructure, Java is vastly more mature in the enterprise market: even if Atwood's law predicts that we will get node.js for IBM's Z/OS mainframes [if we haven't already], Java is already on big iron. Which is to say it scales both up and out.
But again "best" really comes down to the relative value of "it's time to earn" versus "it's time to learn".
Even if it wasn't better, the best language to use on a project is the one you already know. So still Java
I recommend something with non-blocking IO. I suggest Lua-Resty on Nginx.
Some devices I've tried:
Sensi thermostatWink spotter (no longer available)Dahua security cam
Lockitron was hopefully going to be used for access, but it didn't work out.
I've considered adding a tablet for guests to lookup instructions for the house.
I have an "EKM metering" (ekmmetering.com) gas meter that can (at some point) be connected to a pulse counter - they have a device that can tie your electric, water, and gas usage into a graph on the net (and they have an API).
Tried a wemo light switch - it sucks.
I have an Ambient Weather station that feeds current weather stats to weather underground.
For example, AMZN is frequently undervalued. If you read analyst reports, there are scarce mentions of EC2, almost as if the 23 year old bankers writing the reports don't even realize Amazon has a cloud business. All the reports of "competition" are focused on Amazon retail competition, no mention of google cloud, microsoft, etc..
And yet EC2 is absurdly profitable, with margins far higher than Amazon's retail business. But you wouldn't know that if you just listened to the hot air coming from "analysts," which is exactly what institutional investors listen to.
I've had pretty good returns just trusting my own gut and only investing in tech companies where I am confident I know more than the bankers. If you read the analyst reports, it will usually be pretty clear whether they're making an accurate assessment of value.
Quantopian is literally the single most disruptive product in personal finance that I know of: https://www.quantopian.com/
(Not affiliated in any way. Just a really happy user.)
If you're looking to pick specific stocks, this isn't the tool for you. But I want something that gives me control at a high level (how much risk are you willing to take?), but takes care of the details for me^4. And Betterment gives me that. It's really a "set it and forget it" solution.
(Note: I interviewed at Betterment, but didn't get an offer. My friend's brother is employed there on the financial side. I have no financial stake in Betterment other than the money I've invested there.)
 The fund with highest fees I have is Vanguard Emerging Markets Government Bond ETF, at a 0.34% fund fees. One other fund is 0.25%; everything else is below 0.20%. These expensive funds are at low percentages of my portfolio.
 The most you'll pay is 0.35%: https://www.betterment.com/pricing/. If you have at least $10k, you'll pay 0.25%.
 http://support.betterment.com/customer/portal/articles/98745... see "Sell/Buy Rebalancing".
 You tell Betterment what your risk tolerance is, and it picks funds for you, and target levels of these funds. It will automatically purchase these funds in the right amounts.
Curious how betterment will do against WealthFront. On the longer run, I am thinking about splitting the money two ways and put in a bit with both Betterment/Wealth Front as a strategy, possibly.
You can design portfolios from 24,000+ stocks and funds, and backtest it as you build it. Helps you understand how input (each holding) affects the output (historical performances) in a "build-to-think" way.
If you frequent finance/investing related parts of Reddit, you might have seen it. It's the official tool of /r/portfolios now.
* Full disclosure: I designed this tool.
https://stockcharts.com/ Great chart to guide you in reading technical analyses.
Full disclosure: I used to work here.
* Research: Yahoo/Google Finance
* Stock Screen: finviz.com/screener.ashx https://stockflare.com/landing
* Portfolio Visualization(Handy):http://hellomoney.co/
* Portfolio Optimization: https://www.portfoliovisualizer.com/backtest-asset-class-all...
https://lab.madfientist.com/ - track your FIRE date - Financial Independence Retire Early, otherwise known as FU money (my date is Dec 2022)
http://www.mrmoneymustache.com/ - learn how to save and invest. And no, you dont have to be as frugal as Mr Money Mustache.
https://www.reddit.com/r/financialindependence/ - read the sidebar resources and ask questions here if they arent answered
Your bank does give them the data.
The explicit association between your product an Pokmon may be worse than the actual name clash itself.
For instance, suppose I manufacture mini submarines and I name one of them Seaking. Well, guess what, that is a Pokmon character name. It's plausible that this is a complete coincidence and I can get away with that claim even if I did in fact get that from the Pokmon name. If I broadcast the Pokmon association, then that could get the attention of someone at Nintendo; they could come to the conclusion that I'm trying to use their business to promote mine somehow.
Just consider the name carefully and how plausible it is that you came up with it independently, considering factors like: how weird is the name? Are you known to others to be a big Pokmon fan? Have you blogged or tweeted anything about Pokmon, and especially that Pokmon?
Also, assuming that your product isn't directly related to video games, people are going to ask how you came up with the name. Are you ready to explain that your company is named after a teleporting cat that can be found in the woods and has super powers?
My reply was something along the lines of "I don't pursue certifications, but learning that I can benefit from, you can, and can benefit the organization. 90%+ of people with such certifications can't demonstrate 10% of what was in the syllabus, and you know this is true."
This question was general, but I directed it towards a Learning Managment System which I implemented in a past company. There are props for implementing an LMS in one's org too. This was quite special (video, interactive, nice UI), but anything at a basic level will get you noticed as a 'strategic thinker'. Do it if you're (the figurative reader) doesn't have one already.
"Does the system offer certification?"
"Of course it does, but it also implements a development plan for anyone on any course, for their management to rate their implementation of skills learned." Closing the loop in performance assessment; a bit harder.
Demonstrate learning, don't just brag about it. MOOCs are fantastic, and to take part as a contributor (to a larger, fee paid, internal, or open MOOC) is to release years of learning and understanding you may have, that others don't, and as a participator, to harvest that cerebral mass of others and yourself.
Use it, implement it, criticize it, grow it. People are sharing, share back by whatever means, and demonstrate you do so; that principal is priceless and makes certification at whatever cost worthless. Though by doing so, monetary return is not denied.
These courses are not going toake you into professional in the field, you'll need more than just one certificate for that. But they're a good way to explore what you'll be doing in a given field and they're a great adjunct to any formal education you may have.
I don't know what to do. I think I'm either burning out or burnt out some time ago but just don't know it. Either way, this thread is very enlightening.
You're working too much, and some of it is under your control. Stop working on your personal projects for a bit. This gives you time to rest, and think clearly.
Do different work. If that means taking a job, as you mention, then fine, do that for awhile. A compromise would be to work for a contracting agency; there are full-timish yet time-limited jobs, so you can let someone else tell you what to code, yet can still leave the job without any social disapproval. Or just work for a company for awhile.
When you're in a rut, get out of the rut. Do something different, whatever that means to you.
I'm actually in the same boat as you are and am planning to quit my job and do nothing, starting next month. Just gaze at stars from high altitude and realize that this world is big. Job and stress are small things that should not matter in one's life. Then one day you might wake up and find motivation to work less, earn more. At least I hope to do the same.
1) Play mindless video games into the night. I kept having nagging guilt in my mind and had to force myself to ignore it.
2) Buy some books. I have them sitting on my desk. Just haven't been able to will myself to read any fiction (feel guilty about indulging myself). I did manage to read a few non-fiction books that I was interested in. So, baby steps.
3) Hang out with friends/spouse. Realize it is okay to do NOTHING for a bit.
I'm lucky this time. My passion has come back and I can code better than ever. But I am taking this experience as an important lesson. Need to be careful to not get burned out in the future.
Edit: I also let my online learning subscription (won't name it since I have nothing bad against their product) expire on purpose.
You may feel more rested and be tempted to stay up later. Don't do that. Get your 8 hours, every night.
I have a couple of techniques that work for me.
- Taking breaks. Sometimes it's reading HN, other times it's preparing a small meal, or just walking around, or whatever.
- Mental time off. When I have something stressful with a client or there is some big meeting set for a few days from now I prepare and that's it. When I'm comfortable or even if I'm anxious I just tell myself, "I'm not thinking about this again until such and such day or time." It's really empowering and works. Probably the best thing I do.
- Yoga, just a little to loosen up, I like Tara Stile's videos on YouTube, they are for all ability levels.
- Mobility work. One good example is the Limber 11. Learn about your body. A foam roller, a ball, and some light aerobic work get your blood flowing and endorphins going. It just feels good. Also a little time at the gym you get to see other humans and it can be mentally relaxing since your body is doing the work instead of your brain.
- Skydiving. It's a sport that I really enjoy. I know it sounds odd but as soon as you step on a plane the rest of the world just goes on hold. You're focused on that jump and what the objective is (4-way, competition, whatever) that nothing else really matters. It's a common theme with skydivers. Perhaps you can find something similar in your life.
- Learning. I enjoy learning about new things and it's a mental break.
Just take it easy, do what you do well, learn how to turn focus on and off. It a skill that you just have to work on like anything else.
I would consult a professional (starting with a psychiatrist to get your chemicals back in balance) and consider some sort of meditative activity. Like Tai Chi, or playing guitar, or whatever. Or even meditation.
Sleep, eating well, exercise, taking the right medications, avoiding stressful situations and finding ways to destress - you hear these all of the time, and they are things that people still don't do anyway. If you don't, now would be the time to start.
If you are feeling unexplained pains, consider starting an SNRI antidepressant such as Effexor, otherwise consider a plain SSRI. This provides an armoring effect against stress without interfering with the natural process of maturation.
Take a vacation.
Put your side projects on the shelf for a while or hire somebody else to do them while you bring your current engagement to an honorable conclusion if that is at all possible.
It boils down to a choice between saving your sanity and continuing to work in the field, or burning out and quitting-- losing a major income stream in the process.
Is this one client worth that much?
If you're like me, sometimes that requires a self-applied kick to the posterior, but it's usually followed by "Why didn't I do this sooner?" and its sibling, "Why go home?"
If you can, go on vacation to a remote island with little communications.
Works for me.
Tagaloop does not time-out or re-authenticate for you, and since I'm not selling the service I can't offer 2FA, but of course if you wanted to build a company out of this stuff it's open-source. In addition nermal makes the deliberate decision to not support "seek" operations, so it does not e.g. store a header field which could then be scanned in advance to index a bunch of concatenated binary strings -- this is not bad for password storage where the metadata outnumbers the data by a factor of 2 or 3 so there's no point, but other applications like storing an encrypted archive of files might suffer.
I had similar concerns about how it felt that password gorilla remained unchanged for periods of time, regardless of whether I would know if there was a vulnerability or not. It was more...it felt stable (which was fine) but not "this will be here forever!" to me. I recognize I could've forked it (or something similar) but I don't (yet) know tcl/tk and don't feel comfortable "owning" my own password manager for security-related stuff.
I can recommend keepassx/family (I had, long ago, chosen password gorilla for Windows & Linux support) but, at this point if you are moving, find something you are comfortable with (that's updated!).
It uses GPG.
Sticky notes are a hallmark of bad security, but that doesn't mean a pen-and-paper approach has to be ruled out entirely. Depending on how you answered the last two questions, a small notebook containing the passwords written out in some format other than plain text could be a surprisingly viable contender for any software password manager.
Is there anything particularly security related that is concerning you regarding pw-gorilla vulnerabilities?
So far I can recommend 1pass, though its not for free. If you have any particular concerns with 1pass security wise I would be interested too (except its closed source).
I reference patio11 on this topic a lot: You'll generally get one of 3 responses when you ask.
1) 'No'. This is useful - why not? What would need to change?2) 'Yes'. This is the most dangerous response. It's impossible to tell a polite response from a promising prospect. Plenty of new businesses chase the wrong product development strategy because "people said they would buy this". What people say and what people do, especially when it comes to money, are different things.3) "Can I buy this from you right now? How much?" This is the only 'good' response for the state of your current product. If people don't want to buy it now (sign up, whatever) then you haven't found the fit yet.
I'm going through this again with a new business. Lots of the second response - not enough of the third, so much as I'd love to ramp up the marketing I know the product and how I'm explaining it just aren't ready yet.
You can always feel when product/market fit isnt happening. The customers arent quite getting value out of the product, word of mouth isnt spreading, usage isnt growing that fast, press reviews are kind of blah, the sales cycle takes too long, and lots of deals never close.
And you can always feel product/market fit when its happening. The customers are buying the product just as fast as you can make it or usage is growing just as fast as you can add more servers. Money from customers is piling up in your company checking account. Youre hiring sales and customer support staff as fast as you can. Reporters are calling because theyve heard about your hot new thing and they want to talk to you about it. You start getting entrepreneur of the year awards from Harvard Business School. Investment bankers are staking out your house. You could eat free for a year at Bucks.
I am also a part of a startup and owned by a website http://resumeplus.us. I think this answer helped you and I wish all the success for your bright future.
The book is not focused on failures, but it's full of really good advices on what to do when a company is moving into disaster.
- 'DEC is Dead, Long Live DEC' (one of the best books I've read on the failure of a tech firm)
- 'Dealers of Lightning: Xerox PARC and the dawn of the computer age'
- 'The Supermen: The Story of Seymour Cray and the Technical Wizards Behind the Supercomputer'
- 'When Smart People Fail' by Carole Hyatt and Linda Gottlieb (I have the 1986 edition, I believe a later edition is also available; this book is well written but it is so good, complex, and mature that I had to read it several times to fully understand it, and I still try to read it at least once every year to refresh my memory)
- 'The Anxious Organization' by Jeffrey A. Miller
- 'The Soul of a New Machine' by Tracy Kidder
- 'How to Get Rich' by Felix Dennis. (The title is misleading, this is not one of those books containing superficial, useless advice -- the book offers highly useful, in-depth, practical advice on entrepreneurship, including a brutally honest discussion of Dennis's many business failures [as well as his personal failures], and even a list of the most important business mistakes that entrepreneurs, including Dennis, typically make, and how to avoid them.)
- 'Starting Something: An Entrepreneur's Tale of Corporate Culture' by Wayne McVicker. A little-known book, but absolutely excellent.
- It appears that another user (bhamguy) has suggested 'Startup: A Silicon Valley Adventure' by Jerry Kaplan. Good choice, I support that selection, definitely one of the best books I've ever read on startup failure.
On a general level, there are usually more ways to make fatal mistakesthan there are ways to make things successful.
For example, this terrible wall-of-text absolutely destroyed a pretty 37 Signals-esque 3-column pricing chart in A/B testing:
I didn't believe it, so I tweaked it and ran the test again. Exactly the same result. So those paragraphs stay, with the same unordered order, goofy typography and everything else. Nobody touch anything! It's perfectly balanced at its local maxima.
- 79$ (solve a business problem and its worth it. There's no difference between 29 or 39 or 79 for a business user with a credit card.)
- $399 (basically max to buy without approval if you're a manager, anything below 500$.)
- enterprise (aka call us, you'll need approval for this internally.) You could add a 799 plan here, or a 1999 plan, etc.
You want to stay away from 9$ and such unless you're selling to consumers, not businesses, in very high quantities (eg. you're netflix).
I have to believe we are all trying to please the bean-counters w/in our own orgs, but it is almost insulting.
Let us notify you when CryFS is stable!
Desktop : https://github.com/atom/electron Mobile : https://cordova.apache.org/
A bigger risk is failing because you've built the wrong features. It's harder to change or remove features than it is to build them, and you also don't get the time back for misplaced features. Hence the bias toward starting small.
They fail because they didn't talk to customers, didn't do sales, didn't do marketing, or failed to find a viable service model after all that.
MVP is shorthand for "do the least work customers will pay you for." Customers are shorthand for "people you can find who will pay you."
MVP is quite often abused to mean "here's a thing I made." If you don't have customers, and you can't find customers ... then it's not viable yet, is it?
Here's a thing you can do:
You have a hypothesis that [service you can provide] will be valuable to [people you can find]. Okay, so go check that you can actually find those people. Then talk to them about what they do.
You are not allowed to sell, or ask "would you buy this." Facebook surveys are also right out. You need targeted customers, not a bunch of random people with few common characteristics besides being bored enough to respond to Facebook surveys.
Your objective is to learn about these people. How do you find them? How do they talk about the problem? How do you tell them apart from people who really don't give a shit about the problem?
Once you've got a target customer validated at the talking-to-people level, then you can try building stuff. Start with the least work that you think will get people to pay you. It's probably much smaller than you think, and may involve no code.
You don't need to solve everything that anyone told you about the problem, you just need to do enough to make their corner of the world a little better.
Then, go back and try to do sales. Face-to-face sales is the highest conversion rate condition you're ever going to have access to. It doesn't have to scale to infinity million dollars of revenue. It's validation. (Although it's also quite possible to get to stability on boot sales alone, if you charge enough. Which is the only time I ever want to hear that "with no marketing" meme.)
If you can't sell when the deck is stacked in your favor, you don't understand your customers, or you're working on something they don't actually care about.
Treat stuff as a hypothesis. Then test it. Don't just throw code at the wall either. Code without a customer is not a product, it's just some thing you made. Figure out who the customers are and aren't. Then try to find them & talk to them. Learn about them. Then build.
Nobody failed because their MVP was too minimal. They failed because they didn't have customers & didn't do the work to fix their understanding of the world.
I am however one of the founders of my university aerial robotics team, we are planning the attend the IARC (http://www.aerialroboticscompetition.org/) competition this summer.
One of the big unsolved problems in aerial robotics is high-resolution localization without external sensors. Al the drone acrobatics videos out there use a external tracking system. The current IARC mission aims to push this by requiring complex interaction between flying and ground robots without any external sensors. We are currently trying to solve this by using camera and LIDAR sensors. You can read more on our progress here: http://www.ascendntnu.no/blog/
I would love some sort of email group, i have been looking for something like that for some time. Pleas sign me up if you end up creating one: mattivc[at]gmail.com
That won't solve any of the problems. The symptoms you describe also happen in the Apache Groovy "community", if you can call it that. Although they joined Apache's incubator in April last year (2015) and were promoted to a full project in November, the project manager "chair" privately owns the groovy-lang.org DNS name and if you click on most links for Groovy at Apache, they redirect to groovy-lang.org without any warning. He also keeps a private mailing list of groovy users which he collected by running a weekly newsletter for a year which he no longer maintains, and hasn't merged them with the Apache Groovy users mailing list. They run a separate build system for Groovy treating the Apache process as an add-on process, all against Apache guidelines. He refuses to refer to Groovy as "Apache Groovy" on first use which is what the ASF requires of project managers.
Joining Apache is just another distribution strategy for them, despite the talk in Groovy circles a year ago about getting a proper governance structure. It didn't solve Groovy's problems, and it won't solve MongoDB's.
I have a bigger list that I haven't had time to put on the site. If you'd like them, I'm happy to create an open google sheet for you.
Try searching on developerWorks.
Lynx itself is awesome though, I used to use it a lot in my University days.
There's probably a simpler explanation involving no malice.